On Tue, 4 Jun 2002, Dave Mitchell wrote: > Having said that, I have real, real doubts that Perl 6 will ever be able > to execute Perl 5 code natively. Its not just a case a writing a new > parser and some P5-specific ops; P5 has so many special features, boundary > conditions and pecularies, that to get P6 to execute P5 is a task > equivalent to reimplementing P5 from scratch. I'm wondering if instead, > we continue to maintain the P5 src tree, and embed P5 within P6 (embed in > the sense of Apache and Mod_perl). Sick and ugly, but maybe more practical > than the alternatives. It also means that the P6 src doesn't have to be > saddled with knowing (much) about P5. Eventually of course the P5 bit > would have to be thrown away.
That's exactly what I've been arguing for all along. Grr.... And that's why I see the "package" hack and the new :p5 modifier as having the weight of two features, not the weight of an entire re-implementation of Perl 5. It's really not that difficult to run two interpreters in the same process. I already made Perl and Java run together nicely. If anything the impedence mismatch between Perl 5 and Perl 6 will be even less. Scaffolding is supposed to be ugly. You wouldn't believe how ugly the transitional form between Perl 4 and Perl 5 was, when half the opcodes were interpreted by the old stacked interpreter, and half by the new stackless one. Larry
