From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham
	autolearn_force=no version=3.4.4
X-Google-Thread: 103376,3a1c64628a09855b
X-Google-Attributes: gid103376,domainid0,public,usenet
X-Google-Language: ENGLISH,ASCII-7-bit
Path: 
 g2news1.google.com!news3.google.com!postnews.google.com!s13g2000prd.googlegroups.com!not-for-mail
From: Adam Beneschan <adam@irvine.com>
Newsgroups: comp.lang.ada
Subject: Re: Lack of formal syntax undermines Ada
Date: Tue, 15 Apr 2008 09:08:08 -0700 (PDT)
Organization: http://groups.google.com
Message-ID: 
 <6673d0de-4322-4bfe-9216-5dd491b646e3@s13g2000prd.googlegroups.com>
References: 
 <e99fb94d-da10-41d2-9f20-7a6ce78d4613@p25g2000hsf.googlegroups.com>
	<tDkMj.181245$cQ1.7493@bgtnsc04-news.ops.worldnet.att.net>
	<deb5dcf7-ac00-479a-86f7-6a8d496c7f2f@u12g2000prd.googlegroups.com>
NNTP-Posting-Host: 66.126.103.122
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Trace: posting.google.com 1208275689 15209 127.0.0.1 (15 Apr 2008 16:08:09
 GMT)
X-Complaints-To: groups-abuse@google.com
NNTP-Posting-Date: Tue, 15 Apr 2008 16:08:09 +0000 (UTC)
Complaints-To: groups-abuse@google.com
Injection-Info: s13g2000prd.googlegroups.com; posting-host=66.126.103.122;
	posting-account=duW0ogkAAABjRdnxgLGXDfna0Gc6XqmQ
User-Agent: G2/1.0
X-HTTP-UserAgent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.12)
	Gecko/20050922 Fedora/1.7.12-1.3.1,gzip(gfe),gzip(gfe)
Xref: g2news1.google.com comp.lang.ada:20961
Date: 2008-04-15T09:08:08-07:00
List-Id: <comp.lang.ada>

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