Related articles |
---|
Evaluation of parser generators wclodius@aol.com (1997-12-10) |
Re: Evaluation of parser generators kadhim@spock.cs.colorado.edu (Basim Kadhim) (1997-12-12) |
Re: Evaluation of parser generators thetick@magelang.com (Scott Stanchfield) (1997-12-12) |
Re: Evaluation of parser generators wclodius@aol.com (1997-12-14) |
Re: Evaluation of parser generators wclodius@aol.com (1997-12-14) |
Re: Evaluation of parser generators cwilson@Xenon.Stanford.EDU (1997-12-15) |
Re: Evaluation of parser generators parrt@magelang.com (Terence Parr) (1997-12-15) |
[1 later articles] |
From: | wclodius@aol.com (Wclodius) |
Newsgroups: | comp.compilers |
Date: | 10 Dec 1997 00:33:37 -0500 |
Organization: | AOL http://www.aol.com |
Keywords: | tools, question, practice |
I am considering developing a tool for the source to source
translation from one dialect of a rather complex language to another
dialect. In order to make it as easy on myself and other potential
users as possible, I would prefer to use an automatic parser generator
for as much of the task as possible.
Because of the complexity of the language, I believe that the grammar
would be more legible and maintainable if the generator allowed more
than k tokens of lookahead. I have a slight preference, for LL(k) over
LALR(k) or LR(k).
Because the language is used on a large variety of systems, I would
prefer that the tool be as portable as possible. Most parser
geneerators, seem to have only been tested on Unix systems.
Because I would like the tool to be modifiable by others, the parser
generator should be available for the user community with minimal
restrictions. It would be usefull if the code it generates is in a
widely used language, C, C++, Java, or a Pascal derivative are
acceptable. It would be nice if the generator can be set up to
generate code in the language of interest, as that makes it more
accessible to the community, but that is low on my list of
priorities. It would be very useful if a grammar already existed for
the language (Fortran 90).
So far I have identified the following parser generator systems as
potential candidates:
1. PCCTS 1.3x - well documented and widely used, but much of the
technology has been superceded by ANTLR 2.2x. Output in C or C++.
2. ANTLR 2.2x - not as well documented or widely used, but a more
elegant implementation than PCCTS 1.3x. It appears to have been
developed to allow code generation in more than the original output
language, Java, but that capability seems not to have been used by
anyone at this time.
3. JAVACC - It appears to be well documented and widely used, but is
still in a significant state of flux. The lack of availability of
source code is also a minor problem. Output in Java.
4. Eli - I am overall impressed, by this tool, particularly its self
documenting capabilities, but am concerned at the size of the
distribution, the number of support tools required (Tcl/Tk, Funnelweb,
Tex, etc.), the apparent reliance on gcc, and the lack of ports
outside the Unix world. It does apparently come with the only
available "public-domain" implementation of a Fortran 90 grammar. Even
if I cannot use this tool I hope to use its grammar as the basis of my
effort. Output appears to be in C or C++.
5. PRECC-X - Moderately well documented, but it is not clear how
widely used it is. Output appears to be in C.
6. Cocktail - the latest versions sound very good, but there appear to
be significant constraints on their useage. It appears to have a
Fortran 90 grammar that is not in the public domain. Output appears to
be in Modula 2, Oberon, or C++.
7. Depot4 - appears to be more oriented towards prototyping rather
than full implementations. Output in Java or Oberon.
I would appreciate comments on the above systems, particularly from
those that have used more than one such system. If the comments are
extensive I will try to summarize them. If possible I would like the
comments to address the following concerns:
Availability: What restrictions are placed on the useage and
modification of the tool?
the implication on ease of learning/use? What are the implications for
portability and robustness?
Ease of learning and does the ease of learning assume a familiarity
with other systems a la Pearl's assumption of familiarity with Unix
tools.
Ease of use: how simple and regular is the grammar syntax accepted by
the tool? Is the grammar sufficiently flexible that only rarely does
additional code in the output language need to be included?
Documentation: how extensive and well structured is the documentation?
Extensibility: How difficult is it to extend a grammar without
extensively rewritting the old grammar?
Portability: On what systems is the tool available? What problems have
been found in performing such ports?
Robustness: how often do users have to work around problems with the
tool?
Support in general: how active is the user community and developers in
providing support?
Support tools: Does the system have available parser debuggers etc?
Tree walking: This capability is necessary for source to source
translations and I would prefer not to reinvent the wheel. Does the
tool provide predefined structures for this?
William B. Clodius
[If someone wants to make a comparison table, I'd be happy to put it
on the compilers web site. -John]
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.