Re: Ada 95 grammar for aflex?

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

In article <t6olt4ohqu4la7@corp.supernews.com>,
  "Ira D. Baxter" <idbaxter@semdesigns.com> wrote:

> Even if you are interested in error recovery, you can build
> good error recovery in a table driven parser.

This is arguable. Here's a specific challenge. In the context
of a bottom up table driven parser, implement the error
recovery that GNAT does for semicolon used in place of IS and
vice versa (this is a particularly tough one).

Reall the issue is good vs excellent :-)

> That's impressively fast, but it depends on what you mean by
> "parsing".

I mean determining whether the given string is in the language
and giving a semi-decent error msg if it is not.

> Our automatically generated
> parsers automatically capture identifier
> and other kinds of strings and place them in string
> dictionaries,
> carry out integer and floating point value conversions,
> produce abstract syntax trees,
> capture and attach comments and source line information
> to AST nodes, etc.

This would indeed slow things down (by probably a factor of 2
at most), so we would still be at millions of lines per minute.

> Its still OK.  Even with all
> extra work, and not a lot of optimization, we manage
> to generate parsers that do several thousand lines per second
> (180K lines/minute).   We assume with hard work
> (the kind you do to produce "assembly langauge parsers"),
> we can generate parsers that are twice as fast.

Right, so that is perhaps a factor of 10-100 away from what
I can achieve in my asm program, which is what I would expect.

It is definitely the case that parsing efficiency is not
critical (or should not be :-), so the issue driving table
driven vs hand written parsers is indeed dealing with error
detection and recovery in an excellent manner!



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