Re: Ada to Ada Translator ?

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

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

>It is purported to be more difficult to craft meaningful error messages in 
>LR
>parsers, because LL parsers can explain in detail what was expected but,
>without care in crafting the grammar, LR parsers can lack the context 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 -- 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.

                                         Randy.