Lack of formal syntax undermines Ada

Lack of formal syntax undermines Ada

[usenet]

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

Re: Lack of formal syntax undermines Ada

[Peter C. Chapin]

usenet@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.

Re: Lack of formal syntax undermines Ada

[usenet]

Peter C. Chapin wrote:
> use...@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.
>
[snip]
> 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).

The one true grammar would be the one that the language designers
developed ("our DO ... UNLESS construct should look something
like...")
and committed to in the LRM.

> 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.

The syntax rules in the LRM cannot be non-normative. It is not
possible to deduce the structure of Ada from a version of the
LRM with the syntax rules and examples (also non-normative)
stripped. I was surprised to see Annex P marked as "informative".
I took this as shorthand for a statement of the form:
"This Annex is a collection of the syntax rules presented in other
sections of the document. Because of the dangers of a transcription
error, it is informative only. The syntax rules as they appear in
the other sections are normative"

Long familiarity with Ada may lead to underestimating the
difficulty of interpreting the descriptive rules. Try this
one:

From 2.8 Pragmas
(BTW I am using the 'consolidated' version of the Ada95 RM)

[start of quote]
Pragmas are only allowed at the following places in a program:

After a semicolon delimiter, but not within a formal_part
or discriminant_part.

At any place where the syntax rules allow a construct defined
by a syntactic category whose name ends with "declaration",
"statement", "clause", or "alternative", or one of the syntactic
categories variant or exception_handler; but not in place of
such a construct. Also at any place where a compilation_unit
would be allowed.

Additional syntax rules and placement restrictions exist for
specific pragmas.
[end of quote]

Question:
Can a sequence of pragmas (as opposed to a single pragma)
appear at one of the allowed program locations?

Answer 1:
Yes, the text implies this by saying
"Pragmas are only allowed..."; if
only a single pragma could appear, it would say
"A pragma is only allowed..."

Answer 2:
Yes, because the expansion of the syntactic construct
pragma ends in a semicolon. You are then free to reapply
the rule and use the first limb to add a second pragma.
And so on.

Answer 3:
No, there is no provision in the text for inserting more
than one pragma at each allowed location.

Is it obvious to anyone which answer is correct?

Regards,
Chris Noonan

Re: Lack of formal syntax undermines Ada

[Peter C. Chapin]

usenet@leapheap.co.uk wrote:

> Is it obvious to anyone which answer is correct?

Your example is a good illustration of the sort of problems that arise 
when one tries to use a natural language to specify anything. Alas, 
virtually all programming language standards suffer from this. One could 
argue that we really should write language standards in some kind of 
formal specification language like Z. However, doing so would make the 
standard inaccessible to a vast majority of programmers. Providing a 
detailed and unambiguous grammar in the standard would probably have the 
same effect. I agree that the situation is lamentable, but I'm not sure 
what can be done about it short of addressing issues one at a time as 
they arise.

Peter

Re: Lack of formal syntax undermines Ada

[Eric Hughes]

On Apr 15, 8:26 pm, "Peter C. Chapin" <pcha...@sover.net> wrote:
> One could
> argue that we really should write language standards in some kind of
> formal specification language like Z. However, doing so would make the
> standard inaccessible to a vast majority of programmers.

Why pick?  Have both.  Make the formal standard normative, the human
language expository, and fix defects in the standard and defects in
the exposition separately.

Eric

Re: Lack of formal syntax undermines Ada

[Randy Brukardt]

<usenet@leapheap.co.uk> wrote in message
news:0d5b2ee5-56e7-446f-b29c-564580263c3e@i36g2000prf.googlegroups.com...
...
> I was surprised to see Annex P marked as "informative".
> I took this as shorthand for a statement of the form:
> "This Annex is a collection of the syntax rules presented in other
> sections of the document. Because of the dangers of a transcription
> error, it is informative only. The syntax rules as they appear in
> the other sections are normative"

That is exactly correct. Although there isn't much chance of a transcription
error: it (and Annexes K and L for that matter) are automatically generated
from the rest of the standard when it is formatted. (A number of other
annexes are also constructed this way, but partially from text that doesn't
actually appear in the Standard, so there is more chance of an error in
those. But I believe that K, L, and P are constructed only from text that
actually appears in the Standard, so the chances of error are low.)

                          Randy.

Re: Lack of formal syntax undermines Ada

[Georg Bauhaus]

usenet@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.

Re: Lack of formal syntax undermines Ada

[Adam Beneschan]

On Apr 11, 10:27 am, Georg Bauhaus <rm.tsoh.plus-
bug.bauh...@maps.futureapps.de> wrote:
> use...@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

Re: Lack of formal syntax undermines Ada

[John McCabe]

usenet@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.

Re: Lack of formal syntax undermines Ada

[Robert A Duff]

John McCabe <john@nospam.assen.demon.co.uk.nospam> writes:

> As I understand it, that was deliberate; Ada's feature that functions
> may not have side-effects ...

Ada functions can 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.

Right, that's the theory.  But it only works for some functions, and
some arrays.

- Bob

Re: Lack of formal syntax undermines Ada

[John McCabe]

Robert A Duff <bobduff@shell01.TheWorld.com> wrote:

>John McCabe <john@nospam.assen.demon.co.uk.nospam> writes:
>
>> As I understand it, that was deliberate; Ada's feature that functions
>> may not have side-effects ...
>
>Ada functions can have side effects.

Bugger - where did I get that idea from then (have to admit, it's been
a while since I paid a lot of attention to Ada!)

>>...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.
>
>Right, that's the theory.  But it only works for some functions, and
>some arrays.

Of course, but in principle....

Thanks Bob

Re: Lack of formal syntax undermines Ada

[Adam Beneschan]

On Apr 11, 3:37 pm, John McCabe <j...@nospam.assen.demon.co.uk.nospam>
wrote:
> Robert A Duff <bobd...@shell01.TheWorld.com> wrote:
>
> >John McCabe <j...@nospam.assen.demon.co.uk.nospam> writes:
>
> >> As I understand it, that was deliberate; Ada's feature that functions
> >> may not have side-effects ...
>
> >Ada functions can have side effects.
>
> Bugger - where did I get that idea from then (have to admit, it's been
> a while since I paid a lot of attention to Ada!)

There was an early, pre-1983, version of Ada that had a rule that
functions couldn't have side effects; this version also had "value-
returning procedures" for those cases where you really needed
something that could have side effects with the syntax of a function.
(I think value-returning procedures were allowed to have what are now
referred to as OUT and IN OUT parameters, but I'm not sure.)  Since I
don't remember a rule that functions weren't allowed to call
procedures, I don't know how they expected the side-effect rule to be
enforced; maybe the authors figured they could just decree it to be so
and stick implementors with the burden of figuring out how.
Thankfully, that got dropped before the language became a standard.

This was a long time ago, so of course my memory is hazy.  I haven't
looked to see if this draft version of Ada exists somewhere on the
Internet.

                                -- Adam

Re: Lack of formal syntax undermines Ada

[Dirk Craeynest]

In article <ea84dc3f-a0c6-4c05-aa08-5cf434c30e15@b9g2000prh.googlegroups.com>,
Adam Beneschan <adam@irvine.com> wrote:
[...]
>There was an early, pre-1983, version of Ada that had a rule that
>functions couldn't have side effects; [...] I haven't looked to see
>if this draft version of Ada exists somewhere on the Internet.

A reference manual for this pre-1983 Ada was published by Springer in the
LNCS series.  Here is the relevant info if you would like to try retrieving
the book in a library:

The Programming Language Ada Reference Manual
Proposed Standard Document United States Department of Defense
Book Series         Lecture Notes in Computer Science
Publisher           Springer Berlin / Heidelberg
ISSN                0302-9743 (Print) 1611-3349 (Online)
Volume              Volume 106/1980
DOI                 10.1007/3-540-10693-6
Copyright           1980
ISBN                978-3-540-10693-7
Subject Collection  Computer Science
SpringerLink Date   Friday, January 20, 2006

If you have or can yet access to Springer's on-line archive you can
download PDF versions of all chapters [1].  What Springer calls "Front
Matter" [2] and "Back Matter" [3] is freely available there (though the
former contains the wrong title page).

[1] <http://www.springerlink.com/content/un24t0851755/>
[2] <http://www.springerlink.com/content/un24t0851755/front-matter.pdf>
[3] <http://www.springerlink.com/content/un24t0851755/back-matter.pdf>

HTH

Dirk
Dirk.Craeynest@cs.kuleuven.be (for Ada-Belgium/-Europe/SIGAda/WG9 mail)

*** 13th Intl.Conf.on Reliable Software Technologies - Ada-Europe'2008
*** June 16-20, 2008 ** Venice, Italy ** http://www.ada-europe.org ***

Re: Lack of formal syntax undermines Ada

[Jean-Pierre Rosen]

Adam Beneschan a �crit :
> There was an early, pre-1983, version of Ada that had a rule that
> functions couldn't have side effects; this version also had "value-
> returning procedures" for those cases where you really needed
> something that could have side effects with the syntax of a function.
> (I think value-returning procedures were allowed to have what are now
> referred to as OUT and IN OUT parameters, but I'm not sure.)  Since I
> don't remember a rule that functions weren't allowed to call
> procedures, I don't know how they expected the side-effect rule to be
> enforced; maybe the authors figured they could just decree it to be so
> and stick implementors with the burden of figuring out how.
The actual statement was:
"Side effects, e.g. assignments to non-local variables, are not allowed 
within functions, whether directly, or indirectly through other 
subprogram calls".

Quite a weak statement, as far as implementation is concerned, actually.

> This was a long time ago, so of course my memory is hazy.  I haven't
> looked to see if this draft version of Ada exists somewhere on the
> Internet.
> 
I doubt it. At that time, paper was governing the world (I only have a 
paper copy of the Green reference manual).

-- 
---------------------------------------------------------
            J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: Lack of formal syntax undermines Ada

[Robert A Duff]

John McCabe <john@nospam.assen.demon.co.uk.nospam> writes:

> Robert A Duff <bobduff@shell01.TheWorld.com> wrote:
>
>>John McCabe <john@nospam.assen.demon.co.uk.nospam> writes:
>>
>>> As I understand it, that was deliberate; Ada's feature that functions
>>> may not have side-effects ...
>>
>>Ada functions can have side effects.
>
> Bugger - where did I get that idea from then (have to admit, it's been
> a while since I paid a lot of attention to Ada!)

Perhaps from the fact that 'in out' and 'out' parameters are illegal for
functions.  As Robert Dewar likes to point out, the effect of this rule
is that functions can have side effects, so long as they are not
properly documented.  ;-)

Functions can modify global variables if they are visible.
Functions can also modify data via pointers.

- Bob

Re: Lack of formal syntax undermines Ada

[(see below)]

On 12/04/2008 13:57, in article wccod8f1ba9.fsf@shell01.TheWorld.com,
"Robert A Duff" <bobduff@shell01.TheWorld.com> wrote:

> John McCabe <john@nospam.assen.demon.co.uk.nospam> writes:
> 
>> Robert A Duff <bobduff@shell01.TheWorld.com> wrote:
>> 
>>> John McCabe <john@nospam.assen.demon.co.uk.nospam> writes:
>>> 
>>>> As I understand it, that was deliberate; Ada's feature that functions
>>>> may not have side-effects ...
>>> 
>>> Ada functions can have side effects.
>> 
>> Bugger - where did I get that idea from then (have to admit, it's been
>> a while since I paid a lot of attention to Ada!)
> 
> Perhaps from the fact that 'in out' and 'out' parameters are illegal for
> functions.  As Robert Dewar likes to point out, the effect of this rule
> is that functions can have side effects, so long as they are not
> properly documented.  ;-)
> 
> Functions can modify global variables if they are visible.
> Functions can also modify data via pointers.

And they can call procedures or entries that can do almost anything.

-- 
Bill Findlay
<surname><forename> chez blueyonder.co.uk

Re: Lack of formal syntax undermines Ada

[John McCabe]

"(see below)" <yaldnif.w@blueyonder.co.uk> wrote:

>On 12/04/2008 13:57, in article wccod8f1ba9.fsf@shell01.TheWorld.com,
>"Robert A Duff" <bobduff@shell01.TheWorld.com> wrote:
>
>> John McCabe <john@nospam.assen.demon.co.uk.nospam> writes:
>> 
>>> Robert A Duff <bobduff@shell01.TheWorld.com> wrote:
>>> 
>>>> John McCabe <john@nospam.assen.demon.co.uk.nospam> writes:
>>>> 
>>>>> As I understand it, that was deliberate; Ada's feature that functions
>>>>> may not have side-effects ...
>>>> 
>>>> Ada functions can have side effects.
>>> 
>>> Bugger - where did I get that idea from then (have to admit, it's been
>>> a while since I paid a lot of attention to Ada!)
>> 
>> Perhaps from the fact that 'in out' and 'out' parameters are illegal for
>> functions.  As Robert Dewar likes to point out, the effect of this rule
>> is that functions can have side effects, so long as they are not
>> properly documented.  ;-)
>> 
>> Functions can modify global variables if they are visible.
>> Functions can also modify data via pointers.
>
>And they can call procedures or entries that can do almost anything.

Thanks to all for that clarification.

Bill - as a matter of interest, are you the "Findlay & Watt" Pascal
bloke?

Re: Lack of formal syntax undermines Ada

[(see below)]

On 12/04/2008 17:25, in article kio1041hiljne2vdj9fkuvierq4bcn4til@4ax.com,
"John McCabe" <john@nospam.assen.demon.co.uk.nospam> wrote:

> "(see below)" <yaldnif.w@blueyonder.co.uk> wrote:
> 
>> On 12/04/2008 13:57, in article wccod8f1ba9.fsf@shell01.TheWorld.com,
>> "Robert A Duff" <bobduff@shell01.TheWorld.com> wrote:
>> 
>>> John McCabe <john@nospam.assen.demon.co.uk.nospam> writes:
>>> 
>>>> Robert A Duff <bobduff@shell01.TheWorld.com> wrote:
>>>> 
>>>>> John McCabe <john@nospam.assen.demon.co.uk.nospam> writes:
>>>>> 
>>>>>> As I understand it, that was deliberate; Ada's feature that functions
>>>>>> may not have side-effects ...
>>>>> 
>>>>> Ada functions can have side effects.
>>>> 
>>>> Bugger - where did I get that idea from then (have to admit, it's been
>>>> a while since I paid a lot of attention to Ada!)
>>> 
>>> Perhaps from the fact that 'in out' and 'out' parameters are illegal for
>>> functions.  As Robert Dewar likes to point out, the effect of this rule
>>> is that functions can have side effects, so long as they are not
>>> properly documented.  ;-)
>>> 
>>> Functions can modify global variables if they are visible.
>>> Functions can also modify data via pointers.
>> 
>> And they can call procedures or entries that can do almost anything.
> 
> Thanks to all for that clarification.
> 
> Bill - as a matter of interest, are you the "Findlay & Watt" Pascal
> bloke?

Indeed I am.

Also the "Watt, Wichmann and Findlay" Ada Bloke. 8-)

-- 
Bill Findlay
<surname><forename> chez blueyonder.co.uk

Re: Lack of formal syntax undermines Ada

[John McCabe]

"(see below)" <yaldnif.w@blueyonder.co.uk> wrote:

>>>> Functions can modify global variables if they are visible.
>>>> Functions can also modify data via pointers.
>>> 
>>> And they can call procedures or entries that can do almost anything.
>> 
>> Thanks to all for that clarification.
>> 
>> Bill - as a matter of interest, are you the "Findlay & Watt" Pascal
>> bloke?
>
>Indeed I am.
>
>Also the "Watt, Wichmann and Findlay" Ada Bloke. 8-)

That was after my time, I studied Electronics at Glasgow Uni 1983-87,
and we were taught Pascal by the computing department using your book
- Second Edition!

Re: Lack of formal syntax undermines Ada

[(see below)]

On 12/04/2008 23:19, in article t7d204p3pf1vamvlshdoveif3a1b3k8l52@4ax.com,
"John McCabe" <john@nospam.assen.demon.co.uk.nospam> wrote:
... 
>>> Thanks to all for that clarification.
>>> 
>>> Bill - as a matter of interest, are you the "Findlay & Watt" Pascal
>>> bloke?
>> 
>> Indeed I am.
>> 
>> Also the "Watt, Wichmann and Findlay" Ada Bloke. 8-)
> 
> That was after my time, I studied Electronics at Glasgow Uni 1983-87,

"Watt, Wichmann and Findlay" came out in '87 (so long ago!),
but I take your point.

> and we were taught Pascal by the computing department using your book
> - Second Edition!

I know.
We've had this conversation here in c.l.a before, you know.
And, unlike me, you are too young to be having a "senior moment".
8-)

Did you use cards on the ICL 2976 for your labs?

Unlike the first edition of "Pascal", which we typeset and made the
camera-ready copy for ourselves, using nroff and a Diablo Hytype daisywheel
printer, the 2nd was "professionally" typeset at the publisher's insistence.

They inserted a space between the ':' and the '=' of every assignment,
and proceeded to expand it to arbitrary widths by justifying every line.
Virtually every page of the galleys had to be re-set.

<Victor Meldrew>
As I said to Brian Wichmann recently, publishers as a category are
possibly the most incompetent "professional" people I have ever had
to deal with. They (almost) make the software "profession" look good.
</Victor Meldrew>

Back on topic (almost): we typeset "Ada" ourselves, using TeX and a laser.

-- 
Bill Findlay
<surname><forename> chez blueyonder.co.uk

Re: Lack of formal syntax undermines Ada

[John McCabe]

"(see below)" <yaldnif.w@blueyonder.co.uk> wrote:

>>>> Bill - as a matter of interest, are you the "Findlay & Watt" Pascal
>>>> bloke?
>>> 
>>> Indeed I am.
>>> 
>>> Also the "Watt, Wichmann and Findlay" Ada Bloke. 8-)
>> 
>> That was after my time, I studied Electronics at Glasgow Uni 1983-87,
>
>"Watt, Wichmann and Findlay" came out in '87 (so long ago!),
>but I take your point.
>
>> and we were taught Pascal by the computing department using your book
>> - Second Edition!
>
>I know.
>We've had this conversation here in c.l.a before, you know.
>And, unlike me, you are too young to be having a "senior moment".
>8-)

What, me and you? Weird! It's been a long time since I was on here
regularly though, so easily forgotten :-)

>Did you use cards on the ICL 2976 for your labs?

No. We used a VAX. I vaguely remember we may have used cards once, in
83, but I think that was for FORTRAN! As a matter of interest, have I
already asked you if you could remember who we might have been taught
by? It was an old, miserable guy who wore tweed a lot as far as I can
remember.

>Unlike the first edition of "Pascal", which we typeset and made the
>camera-ready copy for ourselves, using nroff and a Diablo Hytype daisywheel
>printer, the 2nd was "professionally" typeset at the publisher's insistence.

>They inserted a space between the ':' and the '=' of every assignment,
>and proceeded to expand it to arbitrary widths by justifying every line.
>Virtually every page of the galleys had to be re-set.

LOL - Nightmare!

Re: Lack of formal syntax undermines Ada

[(see below)]

On 13/04/2008 12:51, in article 2os304dte7bu52t4ql3avpba946birp2r1@4ax.com,
"John McCabe" <john@nospam.assen.demon.co.uk.nospam> wrote:
... 
>>> and we were taught Pascal by the computing department using your book
>>> - Second Edition!
>> 
>> I know.
>> We've had this conversation here in c.l.a before, you know.
>> And, unlike me, you are too young to be having a "senior moment".
>> 8-)
> 
> What, me and you? Weird! It's been a long time since I was on here
> regularly though, so easily forgotten :-)

<http://groups.google.com/group/comp.lang.ada/browse_thread/thread/3885b7fd6
6a1db28/e32a7e7bad2ebf54?lnk=st&q=#e32a7e7bad2ebf54>

>> Did you use cards on the ICL 2976 for your labs?
> 
> No. We used a VAX. ....

Was that in a room with 16 terminals in Lilybank Gardens,
using the "HOCUS" system on a VAX 11/750?

> As a matter of interest, have I
> already asked you if you could remember who we might have been taught
> by? It was an old, miserable guy who wore tweed a lot as far as I can
> remember.

I can think of one or two candidates (neither being me!).
Was he tall and gaunt; or shorter, moustached, and a heavy smoker?
 
>> Unlike the first edition of "Pascal", which we typeset and made the
>> camera-ready copy for ourselves, using nroff and a Diablo Hytype daisywheel
>> printer, the 2nd was "professionally" typeset at the publisher's insistence.
> 
>> They inserted a space between the ':' and the '=' of every assignment,
>> and proceeded to expand it to arbitrary widths by justifying every line.
>> Virtually every page of the galleys had to be re-set.
> 
> LOL - Nightmare!

Our most recent effort:
<http://www.amazon.co.uk/Programming-Language-Design-Concepts-David/dp/04708
53204/ref=sr_1_1?ie=UTF8&s=books&qid=1208095483&sr=1-1>
was re-set by the publisher, using our .doc files, in their "house style",
and they managed to make it less legible, in my opinion, than our originals.
Ho hum.

At least it contains a fair account of Ada, showing its advantages,
especially for concurrency, over the other languages covered.
This despite opposition from the publisher and anonymous reviewers.
It seems that complete ignorance of Ada is no bar to pontificating about it.

-- 
Bill Findlay
<surname><forename> chez blueyonder.co.uk

Re: Lack of formal syntax undermines Ada

[John McCabe]

"(see below)" <yaldnif.w@blueyonder.co.uk> wrote:

>> What, me and you? Weird! It's been a long time since I was on here
>> regularly though, so easily forgotten :-)
>
><http://groups.google.com/group/comp.lang.ada/browse_thread/thread/3885b7fd6
>6a1db28/e32a7e7bad2ebf54?lnk=st&q=#e32a7e7bad2ebf54>

Oh dear - only 5 and a bit years :-)

>>> Did you use cards on the ICL 2976 for your labs?
>> 
>> No. We used a VAX. ....

>Was that in a room with 16 terminals in Lilybank Gardens,
>using the "HOCUS" system on a VAX 11/750?

HOCUS sounds familiar, and it could have been in Lilybank Gardens, but
I can't remember off-hand. I think it was quite a small room in an
older building. It definitely wasn't anything like the Boyd Orr or
Rankine Buildings, and I don't remember it having been the main
building so....

>> As a matter of interest, have I
>> already asked you if you could remember who we might have been taught
>> by? It was an old, miserable guy who wore tweed a lot as far as I can
>> remember.

>I can think of one or two candidates (neither being me!).
>Was he tall and gaunt; or shorter, moustached, and a heavy smoker?

Probably shorter, but I don't remember him having a moustache. Whoever
he was, he didn't like people throwing paper aeroplanes around :-)
There's a vague chance his name was something like Watt.
 
>Our most recent effort:
><http://www.amazon.co.uk/Programming-Language-Design-Concepts-David/dp/04708
>53204/ref=sr_1_1?ie=UTF8&s=books&qid=1208095483&sr=1-1>
>was re-set by the publisher, using our .doc files, in their "house style",
>and they managed to make it less legible, in my opinion, than our originals.
>Ho hum.
>
>At least it contains a fair account of Ada, showing its advantages,
>especially for concurrency, over the other languages covered.
>This despite opposition from the publisher and anonymous reviewers.
>It seems that complete ignorance of Ada is no bar to pontificating about it.

Re: Lack of formal syntax undermines Ada

[(see below)]

On 13/04/2008 20:34, in article son404d3f74k4g2pu5h4rlppm69cmj175a@4ax.com,
"John McCabe" <john@nospam.assen.demon.co.uk.nospam> wrote:
...
> HOCUS sounds familiar, and it could have been in Lilybank Gardens, but
> I can't remember off-hand. I think it was quite a small room in an
> older building.

Yes, that was LBG/HOCUS.

I wrote HOCUS, actually, to make Unix usable for beginners.
I still have the source, which is 90% shell commands.
In 1996 we used a cut-down version of it to deliver
our first Ada95 labs, which had Sun compile/execution servers
with Macs as file management/editing thin clients (they replaced
the file-related commands of HOCUS).

>>> As a matter of interest, have I
>>> already asked you if you could remember who we might have been taught
>>> by? It was an old, miserable guy who wore tweed a lot as far as I can
>>> remember.
> 
>> I can think of one or two candidates (neither being me!).
>> Was he tall and gaunt; or shorter, moustached, and a heavy smoker?
> 
> Probably shorter, but I don't remember him having a moustache. Whoever
> he was, he didn't like people throwing paper aeroplanes around :-)
> There's a vague chance his name was something like Watt.

8-)
From your description, it definitely was not David Watt,
who is tall and something of a snappy dresser.
It was probably Ron Mills.
-- 
Bill Findlay
<surname><forename> chez blueyonder.co.uk

Re: Lack of formal syntax undermines Ada

[John McCabe]

"(see below)" <yaldnif.w@blueyonder.co.uk> wrote:

>On 13/04/2008 20:34, in article son404d3f74k4g2pu5h4rlppm69cmj175a@4ax.com,
>"John McCabe" <john@nospam.assen.demon.co.uk.nospam> wrote:

>>> I can think of one or two candidates (neither being me!).
>>> Was he tall and gaunt; or shorter, moustached, and a heavy smoker?
>> 
>> Probably shorter, but I don't remember him having a moustache. Whoever
>> he was, he didn't like people throwing paper aeroplanes around :-)
>> There's a vague chance his name was something like Watt.
>
>8-)
>From your description, it definitely was not David Watt,
>who is tall and something of a snappy dresser.

I was pretty sure it wasn't David Watt.

>It was probably Ron Mills.

That name doesn't ring a bell. He could have been a heavy smoker
though. I don't know - it was a long time ago. If I ever find my notes
again (I can't remember if I chucked them out when I cleared out my
dad's house or not) I'll let you know :-)

Re: Lack of formal syntax undermines Ada

[Gary Scott]

Robert A Duff wrote:
> John McCabe <john@nospam.assen.demon.co.uk.nospam> writes:
> 
> 
>>Robert A Duff <bobduff@shell01.TheWorld.com> wrote:
>>
>>
>>>John McCabe <john@nospam.assen.demon.co.uk.nospam> writes:
>>>
>>>
>>>>As I understand it, that was deliberate; Ada's feature that functions
>>>>may not have side-effects ...
>>>
>>>Ada functions can have side effects.
>>
>>Bugger - where did I get that idea from then (have to admit, it's been
>>a while since I paid a lot of attention to Ada!)
> 
> 
> Perhaps from the fact that 'in out' and 'out' parameters are illegal for
> functions.  As Robert Dewar likes to point out, the effect of this rule
> is that functions can have side effects, so long as they are not
> properly documented.  ;-)

Sorry, non-Ada nube type question:  How is inter-language calling of 
functions that do allow inout and out arguments handled (say calling a C 
API)?  I assume the restriction only applies to intra-language calls. 
It seems like could create some messiness if the compiler always assumed 
only IN arguments in functions.

> 
> Functions can modify global variables if they are visible.
> Functions can also modify data via pointers.
> 
> - Bob


-- 

Gary Scott
mailto:garylscott@sbcglobal dot net

Fortran Library:  http://www.fortranlib.com

Support the Original G95 Project:  http://www.g95.org
-OR-
Support the GNU GFortran Project:  http://gcc.gnu.org/fortran/index.html

If you want to do the impossible, don't hire an expert because he knows 
it can't be done.

-- Henry Ford

Re: Lack of formal syntax undermines Ada

[Peter C. Chapin]

Gary Scott wrote:

> Sorry, non-Ada nube type question:  How is inter-language calling of 
> functions that do allow inout and out arguments handled (say calling a C 
> API)?

In the case of C, anyway, there are only the (rough) equivalent of in 
parameters. C simulates all other modes using pointers. In Ada one could 
pass an access value to a function and perform the same simulations.

Peter

Re: Lack of formal syntax undermines Ada

[Gary Scott]

Peter C. Chapin wrote:

> Gary Scott wrote:
> 
>> Sorry, non-Ada nube type question:  How is inter-language calling of 
>> functions that do allow inout and out arguments handled (say calling a 
>> C API)?
> 
> 
> In the case of C, anyway, there are only the (rough) equivalent of in 
> parameters. C simulates all other modes using pointers. In Ada one could 
> pass an access value to a function and perform the same simulations.

So there's no possibility of the optimizer making assumptions it 
shouldn't and "simplifying something"?

> 
> Peter


-- 

Gary Scott
mailto:garylscott@sbcglobal dot net

Fortran Library:  http://www.fortranlib.com

Support the Original G95 Project:  http://www.g95.org
-OR-
Support the GNU GFortran Project:  http://gcc.gnu.org/fortran/index.html

If you want to do the impossible, don't hire an expert because he knows 
it can't be done.

-- Henry Ford

Re: Lack of formal syntax undermines Ada

[Robert A Duff]

Gary Scott <garylscott@sbcglobal.net> writes:

> So there's no possibility of the optimizer making assumptions it
> shouldn't and "simplifying something"?

Not sure what you mean.  Can you give an example of such
an assumption?

- Bob

Re: Lack of formal syntax undermines Ada

[Gary Scott]

Robert A Duff wrote:
> Gary Scott <garylscott@sbcglobal.net> writes:
> 
> 
>>So there's no possibility of the optimizer making assumptions it
>>shouldn't and "simplifying something"?
> 
> 
> Not sure what you mean.  Can you give an example of such
> an assumption?
> 
> - Bob
In some languages that have pure functions, the compiler is free to not 
execute the function call if it can determine the return value by other 
means and so eliminate the code entirely (nor inline it).  I was 
thinking thinking there might be situations where a C procedure call 
might be optimized away based upon assumptions of purity (pureness?). 
Probably an outdated question based upon recent posts.

-- 

Gary Scott
mailto:garylscott@sbcglobal dot net

Fortran Library:  http://www.fortranlib.com

Support the Original G95 Project:  http://www.g95.org
-OR-
Support the GNU GFortran Project:  http://gcc.gnu.org/fortran/index.html

If you want to do the impossible, don't hire an expert because he knows 
it can't be done.

-- Henry Ford

Re: Lack of formal syntax undermines Ada

[Robert A Duff]

Gary Scott <garylscott@sbcglobal.net> writes:

> In some languages that have pure functions, the compiler is free to not
> execute the function call if it can determine the return value by other
> means and so eliminate the code entirely (nor inline it).  I was
> thinking thinking there might be situations where a C procedure call
> might be optimized away based upon assumptions of purity
> (pureness?).

Well, normally an Ada compiler/optimizer is not supposed to assume
things that are not true.  There are some exceptions -- for example,
if you suppress run-time checks, and divide by X, and X=0, the compiler
can (and should!) assume that X is not 0.

If a pragma Pure applies to a function, then you had better beware if
that function is written in C!  But normally, the compiler cannot assume
that any function is pure, unless it can prove it to be true.

>... Probably an outdated question based upon recent posts.

OK.  ;-)

- Bob

Re: Lack of formal syntax undermines Ada

[Robert A Duff]

Gary Scott <garylscott@sbcglobal.net> writes:

> Sorry, non-Ada nube type question:  How is inter-language calling of
> functions that do allow inout and out arguments handled (say calling a C
> API)?

Well, C doesn't have anything like Ada's 'out' or 'in out'.

You can pass a pointer in C, and you can do the same in Ada:

    function F (X: access Integer) return Integer;
    pragma Import (C, F);

>...I assume the restriction only applies to intra-language calls.

No, that assumption is wrong.  An Ada function declaration cannot use
'out' or 'in out'.  That's true even if there's a pragma Import,
so the body of the function is in some other language.

If that other language supports something like Ada's 'in out',
well, too bad.  The compiler writer will have to invent
some other way to map that language onto what's allowed in Ada.

>...It
> seems like could create some messiness if the compiler always assumed
> only IN arguments in functions.

Yes, it is an annoying restriction (whether or not you're
interfacing to C).

- Bob

Re: Lack of formal syntax undermines Ada

[Pascal Obry]

Robert,

> If that other language supports something like Ada's 'in out',
> well, too bad.  The compiler writer will have to invent
> some other way to map that language onto what's allowed in Ada.

GNAT supports the pragma Import_Valued_Procedure to do exactly that.

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: Lack of formal syntax undermines Ada

[Florian Weimer]

* John McCabe:

> Bugger - where did I get that idea from then (have to admit, it's been
> a while since I paid a lot of attention to Ada!)

There's the saying that in Ada, functions can have side effects all over
the place, but you can't express that in the function's declaration.

Re: Lack of formal syntax undermines Ada

[anon]

        Ada was design in a similar concept a COBOL.  Where COBOL was 
design for business people to be able to read and understand what is 
happening, Ada was design for government scientist to be able to read and 
modify the algorithm. 

As for BNF for some language includind Ada-95, there is a web site, 
see:

http://cui.unige.ch/db-research/Enseignement/analyseinfo/BNFweb.html

and the direct link to "BNF of the Ada Programming Language":

http://cui.unige.ch/db-research/Enseignement/analyseinfo/Ada95/BNFindex.html

As for your code: YES, it is legal!



In <e99fb94d-da10-41d2-9f20-7a6ce78d4613@p25g2000hsf.googlegroups.com>, usenet@leapheap.co.uk writes:
>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

Re: Lack of formal syntax undermines Ada

[usenet]

anon wrote:

Chris Noonan wrote:
> >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?

> As for your code: YES, it is legal!

I'm not so sure.

The relevant section in the LRM boils down to, in this context:

Pragmas are only allowed at any place where the syntax rules
allow an entry_declaration construct; but not in place of
an entry_declaration construct.

It looks to me that the pragma is appearing in place of
an entry_declaration.

Regards,
Chris Noonan

Re: Lack of formal syntax undermines Ada

[Adam Beneschan]

On Apr 15, 6:22 am, use...@leapheap.co.uk wrote:
> anon wrote:
> Chris Noonan wrote:
> > >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?
> > As for your code: YES, it is legal!
>
> I'm not so sure.
>
> The relevant section in the LRM boils down to, in this context:
>
> Pragmas are only allowed at any place where the syntax rules
> allow an entry_declaration construct; but not in place of
> an entry_declaration construct.
>
> It looks to me that the pragma is appearing in place of
> an entry_declaration.

I was going to explain why you were wrong, but it appears that there's
a slight hole in the language here.  If task_definition (9.1(4)) were
defined as:

   task_definition ::=
      {entry_declaration}
   [private
      {entry_declaration}]
   end [task_identifier]

then it would be clear that your example is legal, since the pragma is
coming at the place of an entry_declaration, and it's not in place
*of* an entry_declaration because the syntax does not require there to
be any entry_declarations.  But the actual definition is

   task_definition ::=
      {task_item}
   [private
      {task_item}]
   end [task_identifier]

   task_item ::= entry_declaration | aspect_clause

Since a pragma can't occur at the place of a "task_item", the only way
the pragma would be syntactically legal here is if one task_item were
present, and then there would have to be either an entry_declaration
or an aspect_clause since the pragma can't occur in place of either
one.

However, this looks to me like just a small error in the RM, and I
don't think it can be used to make a larger point like "Lack of formal
syntax undermines Ada".  There have been many errors in the RM that
were more serious than that, and they've been fixed as they've been
found, and nothing's been undermined.

                                -- Adam

Re: Lack of formal syntax undermines Ada

[Florian Weimer]

> 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.

It shares this property with other many other languages.  For example,
the Definition of Standard ML contains mostly correct formal semantics
of the language, but the grammar suffers from a few ambiguities which
actually arise in practice.  I'm sure there are other examples.

After all, syntax is easy.  Getting the semantics right is the difficult
part.

I agree that some additional formalism might not hurt, but it's probably
better if that effort goes into an improved description of the semantics
(assuming that there are limited resources to create the language
standard).  At least that's how I try to explain this phenomenon to
myself.