Re: Evaluation of parser generators

Basim Kadhim <>
12 Dec 1997 14:52:05 -0500

          From comp.compilers

Related articles
Evaluation of parser generators (1997-12-10)
Re: Evaluation of parser generators (Basim Kadhim) (1997-12-12)
Re: Evaluation of parser generators (Scott Stanchfield) (1997-12-12)
Re: Evaluation of parser generators (1997-12-14)
Re: Evaluation of parser generators (1997-12-14)
Re: Evaluation of parser generators cwilson@Xenon.Stanford.EDU (1997-12-15)
Re: Evaluation of parser generators (Terence Parr) (1997-12-15)
Re: Evaluation of parser generators (Dave Love) (1997-12-23)
| List of all articles for this month |

From: Basim Kadhim <>
Newsgroups: comp.compilers
Date: 12 Dec 1997 14:52:05 -0500
Organization: Dept. of Computer Science, University of Colorado, Boulder
References: 97-12-061
Keywords: parse, tools (Wclodius) writes:

> 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++.

Eli doesn't really require support tools beyond standard utilities
you'll find on any Unix machine. Tcl/Tk isn't strictly required, but
you miss out on a few features if you don't have it (the simplest info
browser is implemented using Tcl/Tk as well as Eli's execution
monitoring/debugging facilities). Most everything else is included in
the distribution (including FunnelWeb and Odin). TeX is only required
if you want to be able to format FunnelWeb documents using TeX. Eli
doesn't rely on gcc at all. It uses whatever C compiler you have on
your system.

While Eli itself has not been ported to systems other than Unix, the
code that Eli generates is highly portable C code that can be compiled
anywhere. (The generated C code can be compiled by a number of C++
compilers as well.) We have reports of people successfully compiling
Eli generated code on Windows platforms.

We do have a complete grammar for Fortran 77 and 90 (they are actually
bundled together). The Fortran 77 specification also includes an
attribute grammar for name and type analysis (and SUIF code

> 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?

Eli is distributed under the terms of the GNU Public License. Code
generated from Eli can for the most part be used without restriction.

> the implication on ease of learning/use? What are the implications for
> portability and robustness?

Eli comes with a large amount of documentation, but as with any system
that provides as much functionality as Eli does, there is a learning
curve. We have found that Eli generated code is highly portable and
very robust.

> 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.

I don't think so, but I may not be objective on this matter. Eli is a
highly integrated system. What this means is that we try to avoid the
clutter of redundant information and use notations which are most
naturally associated with a task (EBNF grammar for syntax, regular
expressions for lexical analysis).

> 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?

The grammar syntax is about as simple as it gets (simple EBNF). No
additional stuff like listings of tokens is required. With a language
like Fortran, most of the tricks happen in the lexer rather than in
the parsing.

> Documentation: how extensive and well structured is the documentation?

There's a lot of it. I think it's well structured, but I am likely to
be biased in this regard.

> Extensibility: How difficult is it to extend a grammar without
> extensively rewritting the old grammar?

Really easy.

> Portability: On what systems is the tool available? What problems have
> been found in performing such ports?

Eli itself is only available on Unix platforms, but the generated code
is highly portable.

> Robustness: how often do users have to work around problems with the
> tool?

Not very often that I'm aware of. We try to provide fixes to problems
as quickly as possible.

> Support in general: how active is the user community and developers in
> providing support?

The developers are conveniently spaced out 8 hours apart around the
globe (Colorado, Germany, and Australia) such that you can usually get
answers to questions and problems pretty quickly.

> Support tools: Does the system have available parser debuggers etc?

What Eli has is an execution monitoring facility that allows you to,
among other things, display the set of rules used in recognizing a
particular piece of input, display the abstract syntax tree generated,
show the contents of the string table, 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?

Eli includes an attribute grammar evaluator for specifying
computations over trees. Note that Eli also builds an abstract syntax
tree for you automatically.

One other tool that is likely to be of interest to you is an unparsing
utility called Idem that is included with the system. It allows you
to quite easily regurgitate the input to the output (and massage it in
any way you like). This has been used for things like generating
instrumented versions of Fortran programs that increment things like
source-level floating point counters.

Please send e-mail to if you have further
questions that aren't answered here.

Basim Kadhim
University of Colorado, Boulder

Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.