Version 1.1 of acs/ac-00055.txt

Unformatted version of acs/ac-00055.txt version 1.1
Other versions for file acs/ac-00055.txt

!standard 3.7.1(03)          03-06-23 AC95-00055/01
!class confirmation 03-06-23
!status received no action 03-06-23
!subject discriminant_association grammar rule found misleading
!summary
!appendix

From: Oliver M. Kellogg
Sent: Friday, March 21, 2003  3:27 PM

3.7.1 Discriminant Constraints

discriminant_association ::=
   [discriminant_selector_name
     {| discriminant_selector_name} =>] expression

The mention of selector_name is misleading here since

selector_name ::= identifier | character_literal | operator_symbol

which is not appropriate.
discriminant_selector_name cannot be an operator_symbol.
OTOH, it might be a selected component.

****************************************************************

From: Pascal Leroy
Sent: Monday, March 24, 2003  3:40 AM

There is a very important distinction between direct_name and
selector_name, irrespective of syntax.  RM95 8.3(24) states that: "A
direct_name shall resolve to denote a directly visible declaration whose
defining name is the same as the direct_name. A selector_name shall
resolve to denote a visible declaration whose defining name is the same
as the selector_name."  So a direct_name requires direct visibility, a
selector_name only requires visibility.  In the context of a
discriminant association, the discriminant is certainly not directly
visible but it is visible because we are in a "special context" (see
RM95 8.3(2)).  (In Ada 83 this was called "visible by selection", see
RM83 8.3(10).)

It's true that a discriminant cannot be a character_literal or an
operator, but to make that explicit in the grammar it would have been
necessary to introduce many different subcategories of selector_name,
and that would have been more confusing.

> OTOH, it might be a selected component.

Surely the discriminant name in a discriminant association cannot be a
selected component...

****************************************************************

From: Oliver M. Kellogg
Sent: Monday, March 24, 2003  1:14 PM

> Surely the discriminant name in a discriminant association cannot be a
> selected component...

Hm, I'll admit right away that I'm not a language lawyer.
I just couldn't find a different term in the syntax rules
to denote a "qualified" name (i.e. a name with possible
package prefixes)

Just to make sure we're talking about the same thing,

  Var : Type_With_Discriminant (D => A.B.C.Some_Enum_Literal);

I.e. I'm talking about the "A.B.C.Some_Enum_Literal"
(I thought that's what the discriminant_association rule
is about?)

****************************************************************

From: Pascal Leroy
Sent: Monday, March 24, 2003  2:03 PM

The selector_name in the discriminant_association rule is the part to the
left of the =>, so it's D in your example.  The part to the right of the =>
can be any expression, including of course a selected component.

****************************************************************

From: Oliver M. Kellogg
Sent: Wednesday, March 26, 2003  1:36 AM

Thanks for clarifying.
I had mentally drifted from the left side of the "=>"
to the right.

I would retain however that the selector_name in the
discriminant_association is still a bit misleading when
writing a parser.

In fact, the whole issue surfaced while I was making the
ANTLR grammar for Ada.

My starting assumption was that the Annex P syntax rules
could be transferred at face value to parser rules.

I don't know whether Annex P was devised with that in mind.
Anyway, it has worked quite well so far, with very few exceptions.
For more detail, see http://www.antlr.org/grammars/ada/TREMULA

****************************************************************

From: Pascal Leroy
Sent: Wednesday, March 26, 2003  2:56 PM

I don't know for sure what was the original intent of the grammar rules
in the RM, but I would guess that they are there mostly for explanatory
purposes.  It is abundantly clear that these rules allow all sorts of
constructs that are illegal in various ways, if only because you cannot
express the italicized parts of the grammar in a parser.  For instance,
the grammar would allow a character_literal or a function_call as the
LHS of an assignment_statement, which is clearly illegal.  If you
blindly follow the grammar rules, you will end up recognizing a superset
of Ada.

One thing I can tell you is that our parser bears no resemblance at all
to the grammar in the RM, especially in the area of expressions and
names.

****************************************************************


Questions? Ask the ACAA Technical Agent