Issue 1682:  Section 2.4.6 : positional notation wrt to unions (notif_service-rtf)
Source:  (, )
Nature:  Revision
Severity: 
Summary: Summary: In section 2.4.6 of the Notification Spec, there"s a discussion about
 positional notation wrt to unions. Examples are given using the
 constraints of the form $.(nn). e.g.,
 $.(3).2 < 128
 
 However, this isn"t syntactically correct. the Compdot syntactic
 category is given as:
 
 <CompDot> := <CompIdent> | <CompPos> | ** the "_" literals **
 
 <CompIdent> must begin with an <Ident> which must begin with an
 aphabetic char.
 <CompPos> must begin with a digit.
 
 <Component> may be empty, in which case an operator like +,-, and, or,
 etc will be expected, but not a "(".
 The same mistake is made throughout Section 2.4.6, in the fifth,
 sixth, and seventh paragraphs. There are also some comments such as "
 .. using run time variables as "$(3).2 < 128" .." in the fifth
 paragraph that don"t make sense. (That example is wrong because a
 runtime variables must be introduced by $<Ident>.) 
 

Resolution: 
Revised Text: 
Actions taken:
July 15, 1998: received issue
February 23, 1999: closed issue
Discussion: 

End of Annotations:=====
Return-Path: <dud@dstc.edu.au>
To: notif_service-rtf@omg.org
cc: issues@omg.org, notification@dstc.edu.au
Subject: Grammar Section Errors
Date: Wed, 15 Jul 1998 11:35:06 +1000
From: Keith Duddy <dud@dstc.edu.au>

Some more from our development team:

In section 2.4.6 of the Notification Spec, there's a discussion about
positional notation wrt to unions. Examples are given using the
constraints of the form $.(nn). e.g.,

$.(3).2 < 128

However, this isn't syntactically correct. the Compdot syntactic
category is given as:

<CompDot> := <CompIdent> | <CompPos> | ** the '_' literals **

<CompIdent> must begin with an <Ident> which must begin with an
aphabetic char.
<CompPos> must begin with a digit.

<Component> may be empty, in which case an operator like +,-, and, or,
etc will be expected, but not a '('.

The example above should read:

 $(3).2 < 128

The same mistake is made throughout Section 2.4.6, in the fifth,
sixth, and seventh paragraphs. There are also some comments such as '
.. using run time variables as "$(3).2 < 128" ..' in the fifth
paragraph that don't make sense. (That example is wrong because a
runtime variables must be introduced by $<Ident>.) 

K
--
__Keith Duddy___CRC for Distributed Systems Technology___+61 7 336 5
4310__
___ http://www.dstc.edu.au/AU/staff/keith-duddy.html ___
dud@dstc.edu.au___
 >>> My Java ORB book is out!!  http://www.wiley.com/compbooks/vogel
<<<

Return-Path: <forys@syl.nj.nec.com>
From: Jeff Forys <forys@syl.nj.nec.com>
To: Keith Duddy <dud@dstc.edu.au>, notif_service-rtf@omg.org
Subject: Re: Grammar Section Errors (fwd) 
Cc: issues@omg.org, notification@dstc.edu.au,
        Mike Greenberg <mjg@syl.nj.nec.com>
X-Face:
O&OwjRZ7Ra<BYSIh:r#\E;#'m|l?}(@F\>=4W}syw:z[[$_I\1~fZ+F=.%)^UaEW4`^aE]@
 2vx7y\6pH|?+]r;iuo!S"p%N:)rc=O,KJT>$hE\*9trN7xjuB[$\)99W^+XSvli(c&r4A<Yu'~XApE
 y>ae4YeW'vR8^``RE-Qs(XcIXJxZ8hlQF%}J?L7t)VX9);"6RrXNN)ptIC0>Z1+R_lY1aL(ojp%
X-Url: http://www.cs.utah.edu/~forys/
Date: Wed, 15 Jul 1998 11:43:32 -0400

	From: Keith Duddy <dud@dstc.edu.au>
	Subject: Grammar Section Errors

	In section 2.4.6 of the Notification Spec, there's a
discussion
	about positional notation wrt to unions. Examples are given
	using the constraints of the form $.(nn). e.g.,
	
	$.(3).2 < 128
	
	However, this isn't syntactically correct.
---
Hi Keith,

Yes, I agree that there is a problem here!
However, I think those examples are correct, and that the grammar
is wrong.  Consider the following union and the structure:

	struct S {			union U switch (short) {
		int A;				case 2: int Y;
		string B;			default: string Z;
	};				};

Without positional notation, we represent their members as
struct.member or union.member.  For example, "$.A" or "$.Z".

With positional notation, $.A becomes $.1 and $.B becomes $.2.
Similarly, I believe that for unions, $.Y should become $.(2)
and $.Z should become $.().

Note that $(2), while correct given the grammar, does not make
sense syntatically.  We are looking at a specific named member of
the union so we should use the dot operator here.

Alternatively, if do not wish to use the dot operator for unions,
we should be consistant so that $.Y becomes $Y.  However, this
creates conflicts with run-time variables and goes against C/C++
grammar rules.  Probably not a good idea.

Therefore, I think we need to make the following change to the
grammar:

	<CompDot>	...
			| <UnionIdent>

	<UnionIdent>	:= ( <UnionPos> )
			| ( <UnionPos> ) . <CompDot>
			| ( <UnionPos> ) <CompArray>
			| ( <UnionPos> ) <CompAssoc>

And then remove the <UnionPos> stuff from <CompAssoc>.

Also, Keith et al. are right in that the run-time variable stuff
for positional notation makes no sense and should be removed.

Please let me know what people think about this.

Jeff

Return-Path: <forys@syl.nj.nec.com>
From: Jeff Forys <forys@syl.nj.nec.com>
To: Mark Briggs <briggs@dstc.edu.au>, notif_service-rtf@omg.org
Subject: Re: Grammar problems
Cc: issues@omg.org, notification@dstc.edu.au,
        Mike Greenberg <mjg@syl.nj.nec.com>
X-Face:
O&OwjRZ7Ra<BYSIh:r#\E;#'m|l?}(@F\>=4W}syw:z[[$_I\1~fZ+F=.%)^UaEW4`^aE]@
 2vx7y\6pH|?+]r;iuo!S"p%N:)rc=O,KJT>$hE\*9trN7xjuB[$\)99W^+XSvli(c&r4A<Yu'~XApE
 y>ae4YeW'vR8^``RE-Qs(XcIXJxZ8hlQF%}J?L7t)VX9);"6RrXNN)ptIC0>Z1+R_lY1aL(ojp%
X-Url: http://www.cs.utah.edu/~forys/
Date: Wed, 15 Jul 1998 13:59:59 -0400

Hi Mark,

First off, creating a context-free grammar from the context-sensitive
Trader Constraint Language was never an objective.  The only goal we
had was to add the the smallest set of extensions to the TCL so that
notification could use the grammar to filter events.

Now, back to your example:

struct A {
    boolean and;
};

This situation may be resolved unambiguously since a <Component> may
not end with a trailing ".".  That is, "$.A." must be a syntax error,
while "$.A.and" must be a <Component>.  As whitespace within a
<Component> is ignored, it is always possible to determine a
syntactically invalid constraint at compile-time:

    $.A. and TRUE       # syntax error
    $.A. and and TRUE   # valid

It looks like we forgot to specify precedence for the "." operator.
Clearly, "." must be atop the precedence hierarchy and therefore
bind very tightly.  Operator precedence for "." needs to be
specified in Section 2.4.2, third bullet.

	The syntactic category <Factor> includes <Ident> and \
<Ident>.
	What is the reason for this? It seems to me that the only use
	for <Ident> in this context is as a check for the existence
	of a runtime variable.
---
The original intention was that enums did not have to be scoped.
One could write "$.color == red or $.color == blue".  The original
trader spec specified <Ident> as part of <Factor>.  To support the
possibility of an enum being a reserved word (e.g., "and", we added
the "\ <Ident>".

There is a note about this in Section 2.4.2, 11th bullet.

	Would the semantics be any clearer if '$' was not used for
	runtime variables at all?
---
Apart from the current conflict with enums, it may be more clear
to some.  Others may more easily associate "$priority" with a
variable (versus "priority"), and an enum as "red" (versus "$.red").
If you're up for a gathering a consensus on all these issues, go
for it.  I'll leave enums and run-time variables as they are for now.

	Possibly I've misinterpreted the intended uses. In that case,
	could someone give me a clue where to find clarification. 
	The documentation in Section 2.4 of the spec seems somewhat
	confused, and the examples even contain some syntax errors.
---
Apart from the mailing list archives, there are no other clues.
If grammar issues are not clear from the Trader or Notification
specifications, then we need to bring them to light now and get
them into our Notification spec.

I would have liked to have spent a lot more time working on the
grammar section for Notification.  Alas, we were also doing an
implementation and I was told that the grammar stuff came second.

There was a period of review, but we all know that you never really
get into the fine details until someone actually tries to do an
implementation from the specification.  Ideally, it would have
been nice to write the spec *after* we had several working
implementations... *sigh*.

If you have *any* questions at all, please ask.

Jeff