Re: Real syntax problems in Ada

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

"Adam Beneschan" <adam@irvine.com> wrote in message 
news:289703e7-1fba-41ce-b781-9e58ff2ec7df@googlegroups.com...
On Tuesday, August 28, 2012 1:13:02 AM UTC-7, Dmitry A. Kazakov wrote:
> What are real problems with Ada syntax as opposed to the imaginary ones
...
>> 2. "end record" instead of "end <record type name>";
>
>Yep, this is one I wish were different.  After working with Ada for about 
>24 years
> I still sometimes type in "end <type-name>" before I catch myself.

I feel that way too, but there is a semantic reason why this isn't possible. 
Specifically, the part after the "is" of a type declaration is a "type 
definition". These are anonymous and can appear in various other contexts 
(anonymous array and access types, for instance). The name of a type comes 
from the type declaration, which is a separate semantic entity (and has 
subtly different rules). I know that Janus/Ada processes "type definitions" 
separately from the declarations, and thus including a name in the anonymous 
part would be difficult to manage.

I once seriously looked at proposing allowing a name in a record type 
declaration, and I couldn't figure out a reasonable way to do so given the 
existing Ada semantics. Figuring out some way to hack the wording so that 
the name associated with the declaration somehow can be matched in the 
definition would seem to require changes all over the standard all out of 
proportion to the size of the problem. So I don't think this is ever going 
to happen.

...
>> 4. "overriding procedure Foo" instead of "procedure Foo is overriding";
>
>It's possible for "overriding" to occur on a procedure body (and necessary 
>in some
> less-common cases).  I'd worry that if Foo has a long parameter list, an 
> overriding keyword
>could get buried in a case like that, making it harder to spot for a 
>reader.  That's a minor point,
>though.

I suspect that if we had added this in Ada 2012 rather than Ada 2005, it 
would have been an aspect -- using separate syntax is overkill for this 
problem. I.e.

    procedure Foo
        with Overriding;

...
>With respect to *syntax* problems (as opposed to new features), my own wish 
>list would
>include allowing a generic formal part to be repeated on a generic package 
>or procedure body.
>(Otherwise, if the specification and body are in different source files, 
>you can't see the definitions
>of the formal parameters when they're used in the body.  I usually just 
>copy in the generic formal
>part as comments.)

As a user, I agree. As an implementer, I would look forward to implementing 
the 5 pages of conformance rules needed for that... :-(

                                              Randy.