Prev: Another compiler problem related to multiple inheritance?
Next: SPARK and static unit checking?
From: usenet on 11 Apr 2008 05:41
Ada does not have a formal syntax. The LRM provides "syntax rules"
section by section, then collectively in Annex P. The resulting
woolly grammar is well-known to be ambiguous (e.g. is X:=Y(Z) an
assignment from a function call, array indexing or something
else?). It mixes lexical and syntactical information. It cannot
be used as the input to a parser generator. The interpretation
necessary via other sections of the LRM risks making the language
as a whole indefinite.

Ada is designed for the construction of high-integrity software
by validated compilers. Would it not be better to have formal
Ada lexical and syntactic rules, expressed in regular expression
and BNF format respectively, even if such rules turn out to be
not particularly readable?

As an example, my parser is having trouble with the fragment:
task type TT is
pragma priority(12);
end TT;
Is this legal Ada95 syntax or not?

Regards,
Chris Noonan
From: Peter C. Chapin on 11 Apr 2008 07:20
usenet(a)leapheap.co.uk wrote:

> Ada does not have a formal syntax. The LRM provides "syntax rules"
> section by section, then collectively in Annex P. The resulting
> woolly grammar is well-known to be ambiguous (e.g. is X:=Y(Z) an
> assignment from a function call, array indexing or something
> else?). It mixes lexical and syntactical information. It cannot
> be used as the input to a parser generator.

Formally the grammar defines a particular language---the language of all
strings generated by the grammar. Using the grammar in the LRM, the
generated language is a superset of Ada (I hope that the grammar in the
LRM at least generates all legal Ada programs... is that true?).
Compiler writers have to add additional checks to remove strings allowed
by the grammar being used and yet illegal according to the rules of the
language. This is very standard, meaning that pretty much all compilers
are created in this way.

It is sometimes possible to express a language restriction by creating a
suitably elaborate grammar that enforces that restriction syntactically.
On the other hand it is sometimes easier to just use a grammar that
allows illegal programs and then enforce the restriction in the semantic
analysis phase of the compiler. Thus there is no "one true grammar" for
Ada or indeed any full scale programming language (as far as I know,
anyway). Instead the grammar used is an implementation detail, defined
at the option of the compiler vendor as part of that vendor's overall
strategy for handling the language. Grammars that appear in language
standards are generally non-normative for precisely this reason. They
exist only to clarify, for the human reader, the descriptive rules
written in the document.

That said, I appreciate your comments about Ada being used in high
integrity applications. It would thus benefiting from a higher degree of
formality than enjoyed by most languages. However, in that case you'd
really like a formal semantics as well as a formal syntax and that is
hard to obtain for a language as complex as Ada. I believe Spark has a
formal semantics (true?) but that is made possible, in part, by reducing
the size of the language considerably.

Peter

P.S. Just because a grammar is ambiguous or not suitable for a
particular parser generator does not make it informal.
From: Georg Bauhaus on 11 Apr 2008 13:27
usenet(a)leapheap.co.uk wrote:

> Ada is designed for the construction of high-integrity software
> by validated compilers. Would it not be better to have formal
> Ada lexical and syntactic rules, expressed in regular expression
> and BNF format respectively, even if such rules turn out to be
> not particularly readable?

How will a syntax that is simple for the parser writer cause
the language to be the best one for the programmer?
In fact Ada was reportedly not designed to make the tool writers
life easier.

Some of the ambiguity might in part have been caused by
an original requirement,
http://archive.adaic.com/docs/reports/steelman/steelman.htm#2
but I can't tell. Actually, there have been arguments in favor
of "overloaded parentheses" here because they permit switching
between array access and function call without notice.
From: Adam Beneschan on 11 Apr 2008 14:13
On Apr 11, 10:27 am, Georg Bauhaus <rm.tsoh.plus-
bug.bauh...(a)maps.futureapps.de> wrote:
> use...(a)leapheap.co.uk wrote:
> > Ada is designed for the construction of high-integrity software
> > by validated compilers. Would it not be better to have formal
> > Ada lexical and syntactic rules, expressed in regular expression
> > and BNF format respectively, even if such rules turn out to be
> > not particularly readable?
>
> How will a syntax that is simple for the parser writer cause
> the language to be the best one for the programmer?
> In fact Ada was reportedly not designed to make the tool writers
> life easier.

Tell me about it!!

But on the other hand, I don't see parser generators as making life
easier for tool writers, either. If you want to do something simple
like scan the source and extract a relatively small amount of
information about the source, they're fine. For anything more complex
than that, I've found that working with tools like YACC can be a
pain. It doesn't find the needed information in an order that's easy
to work with.


> Some of the ambiguity might in part have been caused by
> an original requirement,http://archive.adaic.com/docs/reports/steelman/steelman.htm#2
> but I can't tell.

The rumor I heard was that they wanted to ensure that programs could
be entered on certain ancient keypunch machines. It's a bit ironic,
since a recent thread complained that Ada's handling of Unicode and
its 23,927,511,320,418 characters could be improved, and the original
language requirement wouldn't even let us use the whole ASCII
character set. On the other hand, I suppose it's an advantage to keep
the character set limited, in order to prevent Ada programs from
starting to look like C or Perl or APL or Egyptian hieroglyphics
(sometimes all four look about the same to me).


> Actually, there have been arguments in favor
> of "overloaded parentheses" here because they permit switching
> between array access and function call without notice.

Only if you don't use array accesses on the left of an assignment, or
as an OUT or IN OUT parameter. Actually, I think that's a pretty lame
after-the-fact rationalization, given that the original reason for
avoiding square brackets had nothing to do with any language design
principles. If they had really meant that, they would have also used
the same syntax for record components, so that you could switch from
that to a function call without notice too---that would have been
useful. (Ada 2005's Object.Operation notation gives us some of that,
22 years later.) I'll allow that I've taken advantage of the
parenthesis overloading at times; although switching from array
accesses to function calls isn't a transparent change, it does save a
bit of editing work.

-- Adam
From: John McCabe on 11 Apr 2008 17:25
usenet(a)leapheap.co.uk wrote:

>Ada does not have a formal syntax. The LRM provides "syntax rules"
>section by section, then collectively in Annex P. The resulting
>woolly grammar is well-known to be ambiguous (e.g. is X:=Y(Z) an
>assignment from a function call, array indexing or something
>else?).

As I understand it, that was deliberate; Ada's feature that functions
may not have side-effects means that whether Y is a function or an
array is irrelevant to the user as long as the result is valid. It is
also related to the separation of interface from implementation. Write
the implementation as an array to start with, e.g. for unit test
purposes, then it can be replaced with a function without having to
change the client who uses this interface.

 |  Next  |  Last
Pages: 1 2 3 4 5 6
Prev: Another compiler problem related to multiple inheritance?
Next: SPARK and static unit checking?