> >And what would be a better way of testing this out than being able to
> >make perl6 parse and run perl5 code correctly?
>
> Well, I think it'd be easier to write a proper C parser for perl. Or an APL
> one. Heck, depending on what Larry does a Forth one might be easier. Perl 5
> has a *lot* of little nooks in it that would require some special-case
> code. (Besides, what exactly is perl 5 anyway? It's a rather poorly defined
> thing) It's one of the reasons we're writing perl 6...
right, but if we are being realistic about this whole 'being able to parse and
run other languages' thing, its the best testcase I can imagine. Python has
quite a few special cases itself... I don't see how we could possibly imagine
targeting it without handling special case software.
> > (and I think that a key component
> >ways of making this workable would be to promote a descendent of
> >Parse::RecDescent to be the mechanism that parses perl for *real* and is the
> >basis of micro-perl, etc.)
>
> I doubt the parser will be all in perl for perl 6. Some maybe, and it will
> likely use the regex engine, but I don't see it being all in perl. (And
> yes, I know what Larry's said)
well, I wasn't talking about a perl descendant, but a C descendant... Its the
functionality and ease-of-use that counts. One that could be plugged into perl
as well as being used to parse it..
Ed
