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!nntp-feed.chiark.greenend.org.uk!ewrotcd!newsfeed.xs3.de!io.xs3.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: Mon, 31 Dec 2018 15:45:44 -0600
Organization: JSA Research & Innovation
Message-ID: <q0e2m8$t6b$1@franka.jacob-sparre.dk>
References: <30ba8954-a19e-4c95-b350-798b0276db41@googlegroups.com>
Injection-Date: Mon, 31 Dec 2018 21:45:45 -0000 (UTC)
Injection-Info: franka.jacob-sparre.dk;
 posting-host="rrsoftware.com:24.196.82.226";
	logging-data="29899"; 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:55144
Date: 2018-12-31T15:45:44-06:00
List-Id: <comp.lang.ada>

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

In this particular case, the resolution rule for subtype_mark eliminates any 
nonsense cases.

There's also two practical considerations: one is that with typical grammar 
generators, you usually have to allow more syntax than you want, as 
differentiating between options requires essentially unlimited lookahead. 
(Most grammar generators use a single token lookahead.) In this case, you 
would have a lot of trouble telling between a type conversion and an indexed 
component, if the prefix syntax was different for each.

Secondly, error detection for generated grammars tends to be less 
understandable than hand written error handling. (My understanding is that 
this is a major reason why GNAT uses a hand-written parser.) So allowing too 
much syntactically allows providing better error messages.

For instance, one could easily require "others" to stand alone with your 
grammar. However, if you do that, the error message ends up being something 
like "unexpected |", which is not very helpful.

                              Randy.

<olivermkellogg@gmail.com> wrote in message 
news:30ba8954-a19e-4c95-b350-798b0276db41@googlegroups.com...
> Hi,
>
> RM section 3.2.2 defines
>
>  subtype_mark ::= (subtype_)name
>
> where (subtype_) is subtype_ rendered in italics, i.e. essentially
>
>  subtype_mark ::= name
>
> This looks overly permissive to me, considering 4.1
>
>  name ::=
>     direct_name | explicit_dereference
>   | indexed_component | slice
>   | selected_component | attribute_reference
>   | type_conversion | function_call
>   | character_literal | qualified_expression
>   | generalized_reference | generalized_indexing
>   | target_name
>
> The AARM elaborates in paragraph 4a:
>
> *Ramification*: Note that name includes attribute_reference; thus, S'Base 
> can be used as a subtype_mark.
>
> My question is, why is subtype_mark not defined as follows:
>
>  compound_name ::= identifier { . identifier }
>
>  subtype_mark ::= compound_name [ ' Base ]
>
>
> Similarly, RM section 10.1.1 defines
>
>  parent_unit_name ::= name
>
> Here my question also applies, why not
>
>  parent_unit_name ::= compound_name
>
>
> - Oliver
> (currently fighting ambiguities in the ANTLR grammar caused by laxity of 
> rules)