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 08:20:57 PST Path: supernews.google.com!sn-xit-02!sn-xit-01!supernews.com!feeder.qis.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 14:19:27 -0200 Message-ID: <3A69BA8F.A26A531E@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> 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 980007651 13638562 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:4237 Date: 2001-01-20T14:19:27-02:00 List-Id: Robert Dewar wrote: > > > > 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. Yes, I just understood that the OP was thinking of a "grammar" file. > > 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. I second this, we learned this by hard way while working in a parser for ASN.1 in the earlier 90s... > > 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. I was thinking exactly if this had changed, and it seems that not. Thank you for the present status! > > 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). I remember this being discussed in an earlier paper describing GNAT (and GIGI) by NYU. I passed that to my professors in compiler design at that time (after I finished their courses just in case!). > > 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. If this is a consolation. B. Stroustrup in his book "The Design and Evolution of C++" reports that "...in retrospect, for me and C++ it was a bad mistake [to use YACC].", pg. 69. On your lines it continues with "...C++ was not a new experimental language, it was an almost compatible superset of C - and at that time 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++." So it seems that it still holds: if you're developing a professional compiler, do it by hand! Cesar