[Bug 1804] [FS] editorial: E.1.4.2 Erases

http://www.w3.org/Bugs/Public/show_bug.cgi?id=1804





------- Comment #14 from jmdyck@ibiblio.org  2006-04-18 05:04 -------
(In reply to comment #13)
> 
> Just to make sure we are on the same page, it seems that the main difference
> between our two interpretation is that you assume that non-terminals names
> which are used in the grammar to describe the syntactic objects end up being
> part of the syntactic objects themselves. On the other hand, I assume that the
> syntactic objects are defined independantly of the non-terminal names being
> used and that only terminals are part of those syntactic objects.

I would quibble over some terminology, but I think that's basically it, yes.

> About ASTs. As your point out, the processing model mentions a notion
> of AST. However the specification does not make any specific assumption
> about what such an AST might be. In particular it does not assume that
> non-terminal names should be part of that AST.

Oh, please. Can you point to a usage of "syntax tree" anywhere in which each
node of the tree is *not* labelled with a symbol from the grammar? What would
be the point of such a tree?

> I believe this terminology is used since it is
> quite familiar to developers, but that this does not enforce any specific way
> to represent the syntactic objects resulting from grammar productions in the
> formal semantics.

Well, as I've shown, if you don't "enforce a representation" for objects at
least to the extent of distinguishing between syntax trees and terminal-seqs,
you get conflicting interpretations of the FS. So I don't think you have the
luxury of saying you'll just leave that up to the reader/implementor.

(So actually, I guess this is a technical issue, not an editorial one.)

> The interpretation of non-terminals in the grammar is actually described in
> Section 2.1.2 Notations for judgments, ...
> I don't believe that those description indicate that non-terminals are part of
> the objects themselves.

I'm not sure I agree. For example, it says:
    'Expr1 + Expr2' is a pattern that stands for every addition expression
Now, under your interpretation, the pattern 'Expr1 + Expr2' can be bound to any
series of terminals that can be derived from the phrase 'Expr + Expr'; but such
a series of terminals can occur other than as an addition expression. E.g., in
the FunctionDecl
    declare functon foo () as T+ external
the series of terminals
    T + external
(which can be derived from 'Expr + Expr', and thus matches the pattern in
question) is definitely not an addition expression. So I think the phrasing
fits with my interpretation better.

Anyway, I certainly don't believe that 2.1.2 indicates that non-terminal
symbols *aren't* part of the objects either. Really, it's pretty vague on that
score. (Which is why I didn't include 2.1.2 in the set of sections that
indicate the FS is operating on syntax trees.)

> I agree that maybe some more clarification about what we mean by objects
> (syntactic?) here and how they relate to actual objects
> (values, expressions) is completely specified.

I'd say more clarification is warranted. (By the way, you don't think
expressions are syntactic objects?)

> No matter what I think there is no completely formal way to explicit
> that relationship, but if you want to suggest some text that you
> believe would make it clearer, that would sure be greatly appreciated.

Well, I think first there would have to be a decision about which
interpretation is correct for the FS.

> On the technical front, I am worried that your interpretation will not work
> with most of the auxiliary judgments that are introduced in the spec.

I don't think it's a problem with auxiliary judgments per se, but the example
you raise is a pertinent one. It's vexing that the XQuery grammar doesn't
accommodate the FS better. Mind you, my response would be to fix the XQuery
grammar rather than abandon my interpretation. I quite agree that changing the
official XQuery grammar would be pretty much impossible at this point. However,
I don't have a problem with the FS using a different-but-equivalent grammar.
Note that really, it already *is* using such a grammar, but it's defined
implicitly in the left-hand sides of normalization rules, so nobody notices.

> Finally, I am not sure I see what current problem we are trying to fix. Is
> there really anything broken currently?

Yes. But what is broken depends on your interpretation.

Received on Tuesday, 18 April 2006 05:04:41 UTC