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

Re: Working Group Proposal

Bennett Todd
July 20, 2000 09:27
Re: Working Group Proposal
Message ID:
2000-07-20-12:17:46 Abigail:
> 2000-07-20-11:53:28 Joshua N Pritikin:
> > The part I want to emphasize is that Perl6 should not be written
> > in a low-level language. [...] I propose that perl6 be written
> > exclusively in perl5.
> Writing it in perl5 doesn't make much sense to me.

Makes pretty good sense to me.

> If it's written in perl, it should be written in perl6. That of
> course gives you a bootstrap problem, but that has succesfully
> been solved for other compilers too.

Writing it in perl5 would trivially address the bootstrapping
problem, and as of course we'd also want to ensure that the perl6
implementation would work in perl6 as well, it might amount to the
first substantial and interesting piece of code that works in perl6,
and having that all be a body of known-compatible perl5 code would
set the language out on a nice path, helping to ensure it doesn't
start off with difficulty being properly compatible with perl5.

And perl5 is certainly a sufficiently expressive language to be a
find choice for this job; unless I've missed something this perl6
project isn't here with it's primary goal a radical overhaul of the
language, but rather the implementation.

So I'd turn the question around and say what's the incentive to
write perl6 in perl6 and not in perl5 --- and so, presumably, to be
actively pursuing language incompatibility with perl5 from the very
start, and using that incompatibility in the implementation of
perl6? Is the language perl5 really that deeply flawed?

Another thought just occurred to me. If we're really serious
about back-ending onto a higher-level language, it seems to me
like there'd be big wins if we could manage to avoid committing
completely to to _which_ HLL we back-end onto.  While e.g.
backending onto C would be spiffy for projects like the perl6
compiler itself, where the idea is to produce the fastest possible
precompiled standalone executable, for normal work I'd expect
it'd be nicer to backend onto something like QScheme; it'd be an
easier target, and for normal perl programming, where compile-time
routinely dominates, QScheme could be a really fast and graceful
engine for compile-and-go. Plus, that'd be the natural hook for
other tasks, like e.g. joining up with Guile folks. And who knows,
I wouldn't be too surprised if hooking up with a sufficiently
brilliant scheme compiler couldn't end up delivering faster
standalone executables than trying to do direct to C. This might
not be true in general, but a perl compiler isn't "in general"; as
always, _lots_ of the work would be done by lower-level separate
libraries; the sort of code flow that the compiler would need to
be handling would likely be a great candidate for the sorts of
optimizations that I'd expect a scheme compiler to really handle

-Bennett Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About