Re: Ada to Ada Translator ?

["Randy Brukardt" <randy@rrsoftware.com>]

"Optikos" <optikos@verizon.net> 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.