Front page | perl.bootstrap |
Postings from July 2000
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 well. -Bennett