Le 25/05/2010 20:29, Brian Hurt a écrit :
On Tue, May 25, 2010 at 1:44 PM, Patrick Wright <[email protected]
<mailto:[email protected]>> wrote:
I thought this was interesting enough to re-post; it's a mailing list
post from last year on why an effort to port Perl 5 to the JVM was
abandoned:
http://www.nntp.perl.org/group/perl.perl5.porters/2009/08/msg150099.html
"I'm just pointing out how these language features, some of which have
much broader use cases than the problem they were
intended to solve, interact to basically make non-heuristic parsing
and all forms of static analysis (that I can think of) basically
impossible."
I think the lesson here is "make your language unparseable, and no one
will be able to parse it". My advice to people designing new
languages is to define their grammar in terms of an LALR(1) parser
like yacc, javacc, cup, etc. And to not let shift-reduce or
reduce-reduce conflicts in. One of the big reasons for this is that
any language that is parseable sanely in LALR(1) is parseable sanely
in just about anything else, the converse is not necessarily true.
Fancier parsers such as LL(k) parsers (for example, Bison) or
top-down parsers (parsec, etc.) are great for parsing lanuages that
are hard to parse- the idea is to not make your language such.
Brian
Brian,
javacc is LL(k) and bison LALR or GLR for generalized LR wich extends
the LR algorithm in case of ambiguities by forking
the parser state stack (in fact you have a tree of stacks, a kind of
'cactus' stack) until only one path left.
Rémi
--
You received this message because you are subscribed to the Google Groups "JVM
Languages" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/jvm-languages?hl=en.
