[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