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=unavailable autolearn_force=no version=3.4.4
Path: 
 eternal-september.org!reader01.eternal-september.org!feeder.eternal-september.org!gandalf.srv.welterde.de!news.jacob-sparre.dk!franka.jacob-sparre.dk!pnx.dk!.POSTED.rrsoftware.com!not-for-mail
From: "Randy Brukardt" <randy@rrsoftware.com>
Newsgroups: comp.lang.ada
Subject: Re: Ada grammar rules for names too permissive?
Date: Thu, 3 Jan 2019 16:36:33 -0600
Organization: JSA Research & Innovation
Message-ID: <q0m2ph$ss1$1@franka.jacob-sparre.dk>
References: <30ba8954-a19e-4c95-b350-798b0276db41@googlegroups.com>
 <q0e2m8$t6b$1@franka.jacob-sparre.dk>
 <8f1d7dde-b982-42ff-93d6-5d19dac92f3b@googlegroups.com>
Injection-Date: Thu, 3 Jan 2019 22:36:34 -0000 (UTC)
Injection-Info: franka.jacob-sparre.dk;
 posting-host="rrsoftware.com:24.196.82.226";
	logging-data="29569"; mail-complaints-to="news@jacob-sparre.dk"
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.5931
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.7246
X-RFC2646: Format=Flowed; Original
Xref: reader01.eternal-september.org comp.lang.ada:55181
Date: 2019-01-03T16:36:33-06:00
List-Id: <comp.lang.ada>

<olivermkellogg@gmail.com> wrote in message 
news:8f1d7dde-b982-42ff-93d6-5d19dac92f3b@googlegroups.com...
> On Monday, December 31, 2018 at 10:45:46 PM UTC+1, Randy Brukardt wrote:
>> Ada semantic rules use the syntax rules and vice versa. In this case, one
>> does not want to repeat the various rules for interpreting an expanded 
>> name
>> (which are part of selected_component).
>
> Understood. Thanks for explaining.
>
> I still think that when using Annex P as the direct basis for a parser it 
> would make sense to narrow down the name related rules.
> Along these lines:
> Do you think it would be permissible to "solidify" the italics?
>
> E.g. in the case of subtype_mark, in the implementation grammar there 
> could be an actual rule subtype_name with a much narrower definition.
> That would avoid forcing the parser to jump through the unnecessary hoops 
> of the heavy weight rule `name'.

So long as you aren't representing that the grammar is exactly that of the 
RM, you can make any changes to it that you want. You pretty much have to do 
that in any purely syntactic grammar (indexed_component and type_conversion 
are ambiguous, for instance). As Dmitry said, the grammar of Annex P isn't 
directly useful for much of anything (other than human reading). [Yes, we 
know that, we inherited it from Ada 83 and haven't wanted to change it in 
part because things like ASIS are heavily dependent on the Annex P grammar.]

                          Randy.