Re: [relax-ng] Why I oppose to the current syntax of A.1

[James Clark <jjc@jclark.com>]

 

> However, in my
> opinion, it is terse only because it does not provide enough
> information to readers.

 

I don't think anybody is disagreeing that it would be good to provide more information, specifically information about the types of inherited and synthesized information.  The issue is whether that is better done by augmenting the current notation with types or by switching over to a completely different notation.  As I said before, attribute grammars don't seem to me to completely address this problem: they provide a name, which gives a clue about the types, but they do not explicitly describe the type.

 

> This is not the only reason that I oppose to the current
> syntax.  I think that it is ad-hoc

 

One man's "ad-hoc" is another man's "precisely tuned to the task at hand".

 

> and confuses syntax and
> semantics, since inherited information is described as part of
> production rules but synthesized information is encapsulated
> by {...}.

I think it's a good feature that inherited and synthesized information are sharply distinguished. In my notation the inherited information is encapsulated by () and the synthesized information is encapsulated by {}.  Note that even in your notation the semantics and syntax are intertwined because the semantics depends on the subscripted labels.  I don't think there is any confusion between syntax and semantics in either of our notations.

> Names of semantic attributes free
> readers from the troubles I demonstrated above.

They help but they are an indirect and incomplete solution. I think a blend of the two notations would be the best approach.

 

I think the type of inherited and synthesized information should be given by explicit declarations on each production.

 

Instead of saying

 

 nameClass(elem) ::=

 

we could say something like

 

  Sequence<Element> nameClass(Element elem) ::=

 

or

 

  nameClass(Element elem) returns Sequence<Element> ::=

 

I don't see any need to give a name to the synthesized attribute, since there's only ever one synthesized attribute. I think it's much better to declare the type explicitly rather than use a name to implicitly indicate the type of the synthesized attribute.

 

For example, instead of:

 

  annotatedSimpleNameClass(elem)_x  "|"  annotatedSimpleNameClass(elem)_y
        { (x, y) }

 

how about something like this

 

  annotatedSimpleNameClass_x  "|"  annotatedSimpleNameClass_y
        { x.elem = elem; y.elem = elem; return (x, y) }

 

I'm still not sure I like moving the specification of the inherited attributes away from the non-terminal, but using names instead of position allows the context argument to be treated uniformly as in your notation. Instead of

 

 preamble_c  c.topLevelBody_x
        { x }

 

we can have

 preamble_c  topLevelBody_x
        { x.context = c; return x }

 

One could do

 

  annotatedSimpleNameClass(elem = elem)_x  "|"  annotatedSimpleNameClass(elem = elem)_y
        { (x, y) }

 

but I think that looks weird.

 

James