Re: Ada platforms and pricing, was: Re: a new language, designed for safety !

[Robert A Duff <bobduff@shell01.TheWorld.com>]

Peter Chapin <PChapin@vtc.vsc.edu> writes:

> My understand is that parsing Ada requires name resolution to resolve
> syntactic ambiguities.

Yes.  The syntax rules given in the RM are ambiguous.  For example, in a
context expecting an expression, "X(Y)" could be a function_call,
type_conversion, indexed_component, or slice.  (Did I forget any?)
Likewise, in statement context, that same text could be a procedure_call
or an entry_call.

The "X" in "X.Y" could be a name or an implicit_dereference.

But...

>...This means symbol table management and dealing
> with Ada's visibility rules has to be done while parsing is taking place.

But no, it doesn't mean that, and in fact mixing semantic analysis with
parsing is highly undesirable.  The parser should build a tree, and not
any "symbol table" kinds of things.  The output of the parser should
depend ONLY on the contents of a single source file; it shouldn't need
to know about separate compilation.

Semantic analysis then walks the tree built by the parser.

The way to deal with an expression "X(Y)" is for the parser to build a
tree node that represents "something that looks like a call or a
type_conv or ...".  That is, "a name followed by a parenthesized,
comma-separated sequence of expressions".  That has been called an
"Apply" node in some compilers.

Basically, you need to write a grammar for Ada that is unambiguous, and
that allows a superset of what the RM grammar allows.

When semantic analysis sees an Apply node for X(Y), it looks up X and Y.
It might find X denotes a type, or denotes one or more functions,
or ....

I've done serious work on about 7 or 8 Ada compilers, and this is how
ALL of them worked.  (Here, I'm counting independently designed compiler
front ends, not different host/target platforms.  That is, GNAT counts
as "1 Ada Compiler" I've worked on, even though it supports many
platforms.)

> This probably depends on precisely how one goes about the parse. Perhaps
> it is possible to live with the ambiguity and generate a useful parse
> tree anyway, deferring the rest of the analysis until later, as you say.

Yes, I think that's what I was saying above.

C compilers typically work the other way (mixing parsing with semantic
analysis), to solve syntactic ambiguities related to "typedef".
IMHO any language that forces that design on a compiler is broken.
I'm not sure C forces that design; maybe the typedef problem could
be solved differently, but it doesn't look easy to me.

> I'm not sure right now but it is something I'll need to figure out soon.

- Bob