Re: Lack of formal syntax undermines Ada

On Apr 15, 6:22 am, use...@[EMAIL PROTECTED]
 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