develooper Front page | perl.bootstrap | Postings from July 2000

Re: Working Group Proposal

John Porter
July 21, 2000 10:04
Re: Working Group Proposal
Message ID:

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.

	. Implementation language is well known, stable, powerful,
	  and ubiquitous.

	. 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

1a.  Write and run native Perl5.

	. Portability is a non-issue; anywhere perl5 can run,
	  perl6 can run.
	. Not dependent on other project components; nothing to wait for.

	. 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*.
	. 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.

	. 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.

	. 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)

	. 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*.

	. 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.

	. 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. Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About