From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=0.7 required=5.0 tests=BAYES_00,MSGID_RANDY
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,6784fd29e43ab726
X-Google-Attributes: gid103376,public
X-Google-ArrivalTime: 2001-01-20 11:30:11 PST
Path: 
 supernews.google.com!sn-xit-02!sn-xit-01!supernews.com!newsfeed.stanford.edu!novia!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!nntp2.deja.com!nnrp1.deja.com!not-for-mail
From: Robert Dewar <robert_dewar@my-deja.com>
Newsgroups: comp.lang.ada
Subject: Re: Ada 95 grammar for aflex?
Date: Sat, 20 Jan 2001 19:25:07 GMT
Organization: Deja.com
Message-ID: <94comf$vf7$1@nnrp1.deja.com>
References: <3A6703BD.5D78D62@informatik.uni-stuttgart.de>
 <mailman.979902730.6955.comp.lang.ada@ada.eu.org>
 <949qf7$l43$1@nnrp1.deja.com> <3A68877B.C7AF95D2@uol.com.br>
 <94c7eq$i89$1@nnrp1.deja.com> <3A69BA8F.A26A531E@uol.com.br>
NNTP-Posting-Host: 205.232.38.14
X-Article-Creation-Date: Sat Jan 20 19:25:07 2001 GMT
X-Http-User-Agent: Mozilla/4.61 [en] (OS/2; U)
X-Http-Proxy: 1.0 x58.deja.com:80 (Squid/1.1.22) for client 205.232.38.14
X-MyDeja-Info: XMYDJUIDrobert_dewar
Xref: supernews.google.com comp.lang.ada:4245
Date: 2001-01-20T19:25:07+00:00
List-Id: <comp.lang.ada>

In article <3A69BA8F.A26A531E@uol.com.br>,
  Cesar Rabak <csrabak@uol.com.br> wrote:
> On your lines it continues with "...C++ was not a new
> experimental language, it was an almost compatible superset
> of C - and at that tim nobody had been able to write an
> LARL(1) grammar for C. The LARL(1) grammar used by ANSI C was
> constructed by Tom Pennello about a year and
> half later - far too late to benefit me and C++."

I find that a bit odd, there has been no problem in
constructing the necessary grammars for parsing C with these
kind of tools, and they have been around for years, but that's
not the issue.

The issues are

a) these tools generate rather slow parsers. This is fixable.

b) these tools generate junk error messages. This is also
quite fixable. GNAT gives better error messages than Ada/Ed,
but at the time, people regarded Ada/Ed as having excellent
error messages, among the best around.

If you are not interested in error recovery, there is
absolutely no difficulty in writing a table driven parser
for C++. The problem with g++ is that it has grown rusty
with all kinds of kludges, and no one has had the nerve
to redo it from scratch which is what was needed :-)

To be fair, many other C++ compilers give equally horrible
error messages, but they do not seem to suffer from the time
penalty in parsing to such an extent.

Parsing should take zero time. In my assembly language scanner
and parser for Ada 83, which runs at something approaching
ten million lines a minute on a fast PC, perhaps more, I have
not run it for a while, parsing takes less than 10% of the
total time (the rest is I/O and lexical analysis).



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