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!nntp-feed.chiark.greenend.org.uk!ewrotcd!newsfeed.xs3.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:20:18 -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:20:18 -0000 (UTC) Injection-Info: franka.jacob-sparre.dk; posting-host="rrsoftware.com:24.196.82.226"; logging-data="20486"; 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:56361 Date: 2019-05-21T17:20:18-05:00 List-Id: Oops, sent too soon: "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... ... > 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. ---- This is just a bunch of babble. Most compilers do all of their semantic analysis using an AST, and that would be the same regardless of the parsing technology. Janus/Ada doesn't use an AST for the entire program, but even in it, the grammar productions are irrelevant once semantic processing starts -- that's all driven by the synbol table and the relevant entites. The quality of semantic error messages is what the compiler writer makes them, and any claim that some technology makes it harder is probably an excuse for doing a bad job. (That's my attitude about bad Janus/Ada messages - I try to improve them, not complain about how hard it is.) Randy.