> 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
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.
James
