On Tue, 17 Oct 2000, Adam Turoff wrote:
> On Tue, Oct 17, 2000 at 07:18:54PM -0400, Bradley M. Kuhn wrote:
> > Adam Turoff wrote:
> > > to write the Perl tokenizer in a Perl[56] regex, which is more easily
> > > parsable in C. All of a sudden, toke.c is replaced by toke.re, which
> > > would be much more legible to this community (which is more of a strike
> > > against toke.c instead of a benefit of some toke.re).
> >
> > Larry brought this up in his talk. Of course, I believe that Larry was
> > sleep-deprived at the time, too. ;)
> >
> > > It was late though. Might have been sleep deprevation talking.
>
> Dammit, I'm not finding the message in the thread, but someone casually
> mentioned writing the important bits of parsing Perl in Perl5, generating
> bytecode, and starting Perl6 by writing the bytecode loader. (Apologies
> for not finding the attribution. Please stand up and elucidate if
> you've had this idea as well.)
That would be me. I wasn't necessarily thinking of emitting p6 bytecode,
though that's certainly possible. At the moment I'm thinking that two
different IRs would be useful. Bytecode would be one, the other being a
preparsed and digested program, which is what I was thinking the p5 code
would give us. (Which would then be sent to the bytecode compiler)
> That approach does have a significant amount of merit. Smalltalk, FORTH,
> Lisp (etc.), and Java work in that manner. That would pose a bootstrapping
> problem if there were no Perl5 to start with.
Luckily we have perl 5. :)
> That should also aid in the testing effort.
I hadn't thought about that, but it would. I'm thinking we need to set up
a bunch of performance benchmarks for p6 development too, though that can
go in as part of the general QA. (Not much Q there if we run slower...)
Dan
