[ebon-discuss] Followup on grammar problems with client relations.

[Joseph R. K. <ki...@ac...>]

This message follows up my earlier issues with client relations.

> The BON grammar specifies indirections in client relations with the
> following rules:

...snip...

> But the textual examples from the Wald=E9n/Nerson text seemingly violate
> this grammar (from Figure B.8, pg. 371):
>
>         NURSE client {patients: LIST[..., PATIENT_ID]} PATIENT
>
> Note that PATIENT_ID is a Class_name without any parameterized
> Indirection_list.  I suggest that the grammar is erroneous, not the
> examples.  At first blush, I take the meaning of the specification of the
> classname in the parameter as a generic type-narrowing, kind of a type
> currying.  Of course, this leaves open the possible semantics for the
> ellipses ("...") construct...
>
> I haven't yet re-read the appropriate parts of the text to understand the
> intent of such constructs.  Therefore, I'm not going to suggest a revised
> grammar at this time.

I've re-read Section 4.2 (pgs 69-86) again.  It seems that I was wrong;=20
both the example in the test suite _and_ the grammar are incorrect.

As seen in Figure 4.14, our test example 8 from Appendix B (Figure B.8) is
actually an erroneous textual specification: the patients and duties
features are actually of type TABLE[], not LIST[].  This explains the
second type parameter, given that LIST only has a single parameter.

Given the type parameter of a generic type can indeed be a generic type
itself, I've modified the grammar rule Indirection_element from

Indirection_element: ELLIPSES_TOKEN
                     | Named_indirection ;

to

Indirection_element: ELLIPSES_TOKEN
                     | Generic_indirection ;

This slightly widens the potential type parameter to include
Formal_generic_name as well, which are simply identifiers.

While this solves the problems with the EBNF grammar and examples, it=20
doesn't help with the resulting problems with the LALR(1) grammar.  Thus,=20
I'm currently wrestling with a shift/reduce conflict inherent in the=20
specification of Client_entities_expression.  Right now it comes down to=20
the fact that a Formal_generic_name is indistinguishable from a Class_name.

More details when they become available...

Joe
--
Joseph R. Kiniry                    http://www.cs.caltech.edu/~kiniry/
California Institute of Technology        ID 78860581      ICQ 4344804