Re: Ada 95 grammar for aflex?

[Robert Dewar <robert_dewar@my-deja.com>]

In article <3A68877B.C7AF95D2@uol.com.br>,
  Cesar Rabak <csrabak@uol.com.br> wrote:
> Robert Dewar wrote:
> >
> > In article
<mailman.979902730.6955.comp.lang.ada@ada.eu.org>,
> >   comp.lang.ada@ada.eu.org wrote:
> > > > [...] I've taken a look at the lexical analyser of gnat
> > [...]
> > >
> > > Where is it? I'd like to take a look at this also, as I
am
> > > looking for an alternative to lex/yacc, ASIS, OpenToken.
> >
> > The lexical analyzer for GNAT can be found in the GNAT
sources,
> > available from any GNAT mirror site.
>
> But, IIRC, it was hand made and not written in a language
like
> [f]lex/yacc. Did this change?

No, but the question (see quote above) was a request
specifically for information on the GNAT lexical analyzer.

To use something like lex for a lexical analyzer in a
production compiler is a real mistake, because the resulting
lexical analyzer is much less efficient than a straightforward
hand written analyzer, tends to produce much worse error
messages, and saves a negligible amount of effort.

Lex is fine for occasional use in generating command language
user interfaces, but it not a tool for real compilers.

As for yacc, this particular tool is dreadfully out of date,
generates perfectly awful error messages (since it is not
informed by decades of work on error recovery), and also if
you are not careful tends to generate slow parsers.

As for the issue of whether a modern up to date parser
generator (see the work of Fisher and Charles, IBM and NYU,
in this area, which was used for Ada/Ed) is the right choice,
or a hand written parser, that's still an arguable discussion.

GNAT is a hand written parser, and is intended as a
demonstration of what can be achieved by hand writing parsers
with respect to error recovery (e.g. its ability to distinguish
between semicolon and IS in subprograms and correct wrong
usage).

Recently there have been discussions of the parser in g++.
Amazingly, this parser takes significant time, indicating one
of the results of less than careful use of automated parsers.
Parsing should take no detectable time if a parser is well
written. There is by the way an active funded project to
replace the g++ parser with a hand written version.



Sent via Deja.com
http://www.deja.com/