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=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM autolearn=ham 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 17:59:49 PST Path: supernews.google.com!sn-xit-02!supernews.com!isdnet!newscore.gigabell.net!fu-berlin.de!uni-berlin.de!200-221-14-196.dsl-sp.uol.com.BR!not-for-mail From: Cesar Rabak Newsgroups: comp.lang.ada Subject: Re: Ada 95 grammar for aflex? Date: Sat, 20 Jan 2001 23:55:26 -0200 Message-ID: <3A6A418E.80F1ADC@uol.com.br> References: <3A6703BD.5D78D62@informatik.uni-stuttgart.de> <949qf7$l43$1@nnrp1.deja.com> <3A68877B.C7AF95D2@uol.com.br> <94c7eq$i89$1@nnrp1.deja.com> <3A69BA8F.A26A531E@uol.com.br> <94comf$vf7$1@nnrp1.deja.com> NNTP-Posting-Host: 200-221-14-196.dsl-sp.uol.com.br (200.221.14.196) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: fu-berlin.de 980042387 13537658 200.221.14.196 (16 [39218]) X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en Xref: supernews.google.com comp.lang.ada:4251 Date: 2001-01-20T23:55:26-02:00 List-Id: Robert Dewar wrote: > > In article <3A69BA8F.A26A531E@uol.com.br>, > Cesar Rabak 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. We agree on these. > > 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 :-) So we're detecting an opportunity for improvement! > > 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. I never thought about this, and in fact with the monolithic binaries they come I can't figure a way to benchmark the parsing of other compilers. > > 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). Taking in account the functions of the parser, it makes all sense to me. In fact it could be considered one of the "quality attributes" of a compiler! So bad life is not so easy. Cesar