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 autolearn=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!feeder.eternal-september.org!gandalf.srv.welterde.de!news.jacob-sparre.dk!franka.jacob-sparre.dk!pnx.dk!.POSTED.rrsoftware.com!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Ada to Ada Translator ? Date: Tue, 21 May 2019 17:15:53 -0500 Organization: JSA Research & Innovation Message-ID: References: <100ad407-090e-4316-9746-a4469568b53e@googlegroups.com> <64883feb-3e49-4c6a-855c-6673068e970c@googlegroups.com> Injection-Date: Tue, 21 May 2019 22:15:53 -0000 (UTC) Injection-Info: franka.jacob-sparre.dk; posting-host="rrsoftware.com:24.196.82.226"; logging-data="6964"; mail-complaints-to="news@jacob-sparre.dk" X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Original X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.7246 Xref: reader01.eternal-september.org comp.lang.ada:56360 Date: 2019-05-21T17:15:53-05:00 List-Id: "Optikos" wrote in message news:a8d0f6ca-d5cf-4831-8803-9c1bb6198116@googlegroups.com... >On Monday, May 20, 2019 at 6:19:55 PM UTC-5, Randy Brukardt wrote: >> "Optikos" wrote in message >> news:64883feb-3e49-4c6a-855c-6673068e970c@googlegroups.com... >> ... >> >Conversely, if you utilize Yacc & Flex, it would be LR(k) bottom-up >> >parser, >> >which would be an admirable accomplishment in its own right. >> >> Why? There are a number of such grammars out there, and Janus/Ada was >> designed from the beginning (in 1980!) using an LALR parser. (That was a >> requirement of the class project at the University of Wisconsin that >> formed >> the basis of Janus/Ada, and we discovered that switching was impractical >> as >> an LL parser was going to be several times larger than the 48K RAM >> available >> on CP/M-80. With some clever storage, we got the LR tables to fit with >> space >> to spare.) > >I said "admirable", not unique. I was speaking in the context of an >open-source >Ada language-translator, not a closed-source one. Which is relevant how? There are (or at least were) a number of YACC grammars for Ada floating around the web. And there's no difficulty in using them... >> >to make "hmmm, it looks like you were trying to do /this/, but I found >> >troublesome /that/ instead" type of error messages. >> >> This is definitely not true and irrelevant at the same time. :-) An LR >> parser has plenty of context (there is always a state that contains a >> vast >> amount of information). The problem (to the extent that there is one) is >> situations where you have already gone a long ways down an incorrect path >> before finding out a problem > >You demonstrated what I was saying: in some LR reductions, the interesting >detail >vis a vis interesting abstraction were a too far away from each other to >easily stitch >back together in a meaningful way, such as for human-friendly error message >that >isn't speaking in compiler-internal speak (or worse, LR >clever-table-compaction-speak). Baloney. Janus/Ada writes messages in terms of deleted/inserted/replaced tokens, and those are always understandable by any human. And as I noted, there's not much point in syntax error correction anyway, as one can only fix one error at a time in any event (and all of the syntax should be in the IDE). > -- Ada luckily does not have many of these. > (The worst one in Janus/Ada is an "is" following a subprogram in a package > specification; you've gone too far for an correction to fix the > situation.) > > >Writing an LR-based (i.e., yacc-based) parser can create an awesome fast > >parser, but to do so requires a generous amount of expanding the base > >language's grammar to consider all the commonplace mistakes to build up > >enough context to emit that aforementioned type of useful error message. > > Maybe for some languages, but there isn't much of that in Janus/Ada's > grammar. Instead, error correction is based on the grammar tables > themselves, and costs for insertion and deletions of tokens. That turns > out > to be cheap, fast, and reliable -- the only issue is getting the costs > right > (and they aren't that critical, they're mainly used to break ties). > > But I think that error messages for *syntax* in a compiler are pretty much > irrelevant these days; it's the IDE's job to check the syntax before > calling > the compiler, and in the IDE you only care about the first error anyway. > Presuming the check is fast enough (and it is on all but the largest > files), > you check, then fix, then check again until it is correct. I didn't say "syntax". My "/this/" and "/that/" are wide-meaning enough to encompass semantic checks as well. LR reductions are often abstracted enough at an index into a table to have (at the surface level without digging again) the easily-available-at-hand contextual information to give good-human-friendly semantic error messages of the category: I thought we were doing /this/ but then you gave me conflicting /that/ semantically. Because they are human-crafted for human consumption, LL parsers tend to not aggressively conflate abstractions as much as LR parser tables try to conflate commonality to avoid combinatorial or exponential explosion. With LR parsers, there is more digging & sifting through what just got successfully (fully-syntactically and partially-semantically) parsed to analyze it. LL grammars do somewhat less of that rediscovery because LL parsers tended to preserve more implicit knowledge of what has been accepted so far. All that I am saying is that LL parsers tend to have more interesting accumulated state implicitly laying around locally that LR parsers need to overtly either accumulate via intentionally-crafted mementos a priori or go digging & sifting through a posteriori.