> Yes, but why not YACC? Is Antlr so much better, or is
> YACC too primitive, or what? IMHO, adding C++ just for
> parsing is not going to happen, so Antlr is not going to
> happen either.
I think the advantage that Barry saw is that ANTLR generates Java in
addition to C, so it could be used in JPython as well. In addition,
ANTLR is more advanced than YACC; it specifically supports full EBNF
as input, and has better mechanisms for conflict resolution.
On the YACC for Java side, Axel Schreiner has developed jay, see
http://www2.informatik.uni-osnabrueck.de/bernd/jay/staff/design/de/Artikel.htmld/
(if you read German, otherwise don't bother :-)
The main problem with multilanguage output is the semantic actions -
it would be quite a stunt to put semantic actions into the parser
which are valid both in C and Java :-) On that front, there is also
CUP (http://www.cs.princeton.edu/~appel/modern/java/CUP/), which has
different markup for Java actions ({: ... :}).
There is also BYACC/J, a patch to Berkeley Yacc to produce Java
(http://www.lincom-asg.com/~rjamison/byacc/).
Personally, I'm quite in favour of having the full parser source
(including parser generator if necessary) in the Python source
distribution. As a GCC contributor, I know what pain it is for users
that GCC requires bison to build - even though it is only required for
CVS builds, as distributions come with the generated files.
Regards,
Martin
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4