Front page | perl.perl6.internals.api.parser |
Postings from December 2000
Re: Now, to try again...
Thread Previous
|
Thread Next
From:
David Grove
Date:
December 17, 2000 11:51
Subject:
Re: Now, to try again...
Message ID:
200012172023.eBHKNGm01815@camel.petes-place.com
Sam Tregar <sam@tregar.com> wrote:
> 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.
Whoah. That's well beyond my understanding of the role of the creoles or
"little languages". From my understaning, we're not wanting to parse C or
Java or Python themselves, but Perl written C-ishly or Java-like or
Pythonicly. My understanding of both the conversations in this area during
the RFC discussions and Larry's speech is that we're wanting to make Perl
look better for spoiled programmers of other languages who want or need
additional, clearer, or specific syntax or syntactic sugar, not become a
full-featured compiler/interpreter for those other languages.
If we're aiming for what I understand to be the goal here, lex and yacc
shouldn't even be in the equation, even if they're perl lex's and yacc's.
If we're aiming to be a complete parsing system for the full parsing specs
of the other languages, or even to provide the ability to hook in those
full language specs, I think everybody (myself especially... this is a
frightened question not a flame) needs a reality check, to define what the
role of the creoles are, and if the larger task is even attainable. Are
they creoles (little languages) that vary from Perl, or are they full
languages that actually do/might need complete parsing separate from Perl?
p
Thread Previous
|
Thread Next