Front page | perl.bootstrap |
Postings from July 2000
Here's my attempt to summarize the issues in detail.
Someone else suggested that it is far too early on the
curve to be considering these questions, but I disagree.
Three approaches:
1. Write perl6 in Perl5
2. Write perl6 in LCL, and translate that into C*.
3. Write perl6 in C*.
Actually 1. has two sub-approaches, which are not mutually
exclusive, but which may follow one from the other:
1a. Write perl6 in Perl5, and run that with perl5.
1b. Write perl6 in Perl5, and convert that into C* using some
perl5 backend (i.e. perl compiler).
Now the pros and cons:
1. Write perl6 in Perl5.
Pros:
. Implementation language is well known, stable, powerful,
and ubiquitous.
Cons:
. There is very little real-world experience with this class
of problem available to bring to bear. (However, it may be
feasible to manually re-engineer some of perl5's C code into
perl?)
1a. Write and run native Perl5.
Pros:
. Portability is a non-issue; anywhere perl5 can run,
perl6 can run.
. Not dependent on other project components; nothing to wait for.
Cons:
. Perl6 will require perl5, and thus Perl6 does not let Perl5
die a natural death.
. Performance will be bad, in terms of both size and speed.
1b. Write Perl5 and compile into C*.
Pros:
. If perl5 is unavailable or undesirable on the target host,
the C* code can be ported.
. A natural bootstrapping path: the Perl5 source can be
replaced with Perl6 once a working perl6 is available.
. Resulting code should have decent performance.
Cons:
. Requires a perl5 backend to generate C* code, which as yet
is vaporware, and may never be anything more.
2. Write perl6 in LCL which compiles into C*. The usual suggestion
is to write the translator in Perl.
Pros:
. The implementation of Perl6 in LCL, and the implementation of
the translator (in Perl), can proceed more or less independently.
. Writing a language translator in Perl is not particularly hard.
. As with (1b) above, building perl6 only requires perl5 and
a C* compiler, which are both essentially ubiquitous.
And the C* code could be distributed directly if necessary.
. LCL, which is some hypothetical language construction language,
is presumably independent of the other languages involved, i.e.
a) the target language (C*)
b) the translator language (Perl, ostensibly)
c) the language being implemented (Perl6)
Thus any of these could be replaced/improved in the future,
including writing the translator in Perl6. (Bootstrap)
Cons:
. LCL has not been defined, and would constitute a significant
chunk of the project's time and effort. And that's before
we can even begin to implement Perl6 in LCL!
3. Write perl6 in C*.
Pros:
. No dependency on perl5.
. No bootstrapping issues.
. C* is well-known and ubiquitous (for some values of C*).
. Better optimizations possible.
. Not dependent on other project components, i.e. don't need to
wait for a working perl5 compiler or for the LCL.
Cons:
. C*, being a LLL, requires great software engineering discipline
to not f up.
Please add any additions or corrections you think of.
Particularly, the various pros and cons need to be weighed for their
importance. Which cons are showstoppers?
For example, I believe that the Cons of Approach #2 above is probably
a showstopper.
Bennett Todd wrote:
> ...if we _do_ wish to
> write perl6 in perl (or in other specification languages, themselves
> implemented in perl), then I would argue that the dialect of perl
> that we should write in should be perl5, at least until and unless
> perl6 gets so far past the simple bootstrapping that time comes to
> actually retire perl5.
Eminently reasonable.
--
John Porter
Aus tiefem Traum bin ich erwacht.