On Sun, 17 Dec 2000, Andy Dougherty wrote:
> Now matter how we slice it, it's going to be very hard for the first
> person to twist perl6 to parse something that is both complex and very
> different from Perl6. And I'm unconvinced that this difficulty ought to
> hold up the entire process. It would be quite ironic if perl6 never gets
> off the ground because we can't figure out how to make 'use Java;' easy.
Good point. Our first goal is to get Perl 6 (whatever that is) up and
running. However, perhaps we should set a secondary goal for ourselves -
choose a simple, well-documented language that we intend to support aside
from Perl 6 in the first release. It would help to keep us honest anyway.
> That's a good question.
>
> Another route to keep in mind is spending effort working on and with
> things such as perl-byacc (and maybe even the yet-to-be-written perl-lex)
> that help turn simple "languages" into perl.
I imagine that each supported language will likely have its own prefered
parsing strategy. Some will be perfectly lex-yacc-able. Some will be
more like Perl than that and would benefit from some hooks into Perl's
existing parser. I think we just need to provide the harness - each
language parser should be written in the way that makes sense for that
lanaguage. If the C frontend wants to call out to GCC to do its parsing
then it should be able to.
-sam
