OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

relax-ng message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

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

> 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) ::=
  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
  annotatedSimpleNameClassx  "|"  annotatedSimpleNameClassy
        { 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
 preamblec  c.topLevelBodyx
        { x }
we can have
 preamblec  topLevelBodyx
        { x.context = c; return x }
One could do
  annotatedSimpleNameClass(elem = elem)x  "|"  annotatedSimpleNameClass(elem = elem)y
        { (x, y) }
but I think that looks weird.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC