comp.lang.ada
 help / color / mirror / Atom feed
From: "Randy Brukardt" <randy@rrsoftware.com>
Subject: Re: Ada grammar rules for names too permissive?
Date: Thu, 3 Jan 2019 16:36:33 -0600
Date: 2019-01-03T16:36:33-06:00	[thread overview]
Message-ID: <q0m2ph$ss1$1@franka.jacob-sparre.dk> (raw)
In-Reply-To: 8f1d7dde-b982-42ff-93d6-5d19dac92f3b@googlegroups.com

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




  reply	other threads:[~2019-01-03 22:36 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-29 18:20 Ada grammar rules for names too permissive? olivermkellogg
2018-12-31 21:45 ` Randy Brukardt
2019-01-01  8:44   ` Dmitry A. Kazakov
2019-01-01 19:49     ` Stephen Leake
2019-01-01 20:42       ` Dmitry A. Kazakov
2019-01-02 19:21         ` Stephen Leake
2019-01-02 20:47           ` Dmitry A. Kazakov
2019-01-03 21:45             ` Stephen Leake
2019-01-03 22:34               ` Jere
2019-01-05 18:46                 ` Stephen Leake
2019-01-07 11:11                   ` J-P. Rosen
2019-01-08 18:58                     ` Stephen Leake
2019-01-04  8:53               ` Dmitry A. Kazakov
2019-01-03 22:39     ` olivermkellogg
2019-01-04  8:58       ` Dmitry A. Kazakov
2019-01-05  8:45         ` Randy Brukardt
2019-01-05 18:50       ` Stephen Leake
2019-01-01 19:46   ` olivermkellogg
2019-01-03 22:36     ` Randy Brukardt [this message]
2019-01-01 19:46 ` Stephen Leake
2019-01-01 21:03   ` olivermkellogg
2019-01-02 19:42     ` Stephen Leake
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox