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: [relax-ng] Why I oppose to the current syntax of A.1


Some of you probably remember that I first reluctantly
suggested attribute grammars for reorganizaing A.1 of the
compact syntax spec.  Although I thought the current syntax
was ad-hoc, I thought it was easily understandable.  However,
after desperately trying to fully understand A.1, I have come
to feel differently.

The current syntax is terse and looks simple.  However, in my
opinion, it is terse only because it does not provide enough
information to readers.  If you read A.1 for five minutes,
you'll think that it is not difficult.  If you spend thirty
minutes, you'll start to feel uneasy.  After two hours, you'll
feel exhausted and admit that you don't understand.  I'm not
surprised to hear that nobody else has found the errors in the
production rules for notatedExceptNameClass,
annotatedSimpleNameClass, and leafAnnotatedExceptNameClass.
(Did somebody *carefully* read {...} attached to production
rules?)


As an example, consider the following production rule in A.1.

annotatedExceptNameClass(elem)  ::=
    leadAnnotatedExceptNameClass(elem)x  followAnnotations(elem)y
        { (x, y) }

This *looks* clear.  Something computed for
leadAnnotatedExceptNameClass and something computed for
followAnnotations are concatenated, and used as the value of
annotatedExceptNameClass.  But what is the "something"?  To
answer this question, you have to examine the production rule
for leadAnnotatedSimpleNameClass.  There, you see

leadAnnotatedSimpleNameClass(elem)  ::=
    annotationsx  simpleNameClass(elem)y
        { applyAnnotations(x, y) }
    |  annotationsx  "("  innerNameClass(elem, x)y  ")"
        { y }

What is this "y"?  You then have to examine the production
rule for innerNameClass.  This difficulty happens everywhere
in A.1.

This is not the only reason that I oppose to the current
syntax.  I think that it is ad-hoc and confuses syntax and
semantics, since inherited information is described as part of
production rules but synthesized information is encapsulated
by {...}.

Attribute grammars are free from these problems.  They clearly
separate syntax and semantics.  They use similar mechanisms
for inheriting and synthesizing information (we can use two
operators if we want to distinguish inherited attributes and
synthesized attributes.)  Names of semantic attributes free
readers from the troubles I demonstrated above.

The only disadvantage of attribute grammars is that it is not
terse (just like XML is not terse).  However, as far as
specifications are concerned, rigorousness and readability are
more impotant than terseness.


Cheers,

Makoto


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


Powered by eList eXpress LLC