W3C home > Mailing lists > Public > public-qt-comments@w3.org > January 2008

[Bug 5332] [UPD] Parentheses around () or fn:error()

From: <bugzilla@wiggum.w3.org>
Date: Tue, 01 Jan 2008 18:49:05 +0000
CC:
To: public-qt-comments@w3.org
Message-Id: <E1J9mAj-0000dF-Lz@wiggum.w3.org>

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





------- Comment #1 from mike@saxonica.com  2008-01-01 18:49 -------
Please ignore the comment about fn:trace() - allowing update instructions to be
traced is a much more complex subject than I thought.

I've been trying to implement the rules that () and fn:error() (and no other
non-updating expressions) are allowed in updating contexts, and the rules are
surprisingly disruptive. The problem is that you can't tell whether one branch
of a conditional, say, is an updating expression until you are well into the
semantic analysis (because you can't do it until function calls have been bound
to the relevant function declarations), and by the time you get to this stage
of semantic analysis, a lot of the original syntactic detail will have been
lost. Not just redundant parentheses, as mentioned in comment #0, but probably
quite a lot else too. Many parsers work by constructing an expression tree in
some kind of "core grammar" that discards syntactic distinctions - in my case,
for example, this reduces typeswitch to an if/then/else construct. 

Ideally the rule that allows () and fn:error() in updating contexts should be
rephrased to work in terms of the type system, so that the rule relates to the
type of the result of the expression, and not to its syntactic form. That's
probably a significant challenge. Short of that, I would suggest two new rules:

(a) If the processor is able to infer that the result of an expression will
always be an empty sequence or an error then it may allow that expression to
appear in a position where an updating expression would be allowed.

(b) If the processor is able to infer that a branch of a conditional/typeswitch
will never be evaluated, then it is allowed to eliminate that branch before
determining whether all branches are consistently updating or non-updating.
(This would be the case if it were a dynamic error or type error rather than a
static error, and one way of achieving this rule would be to reclassify the
error.)
Received on Tuesday, 1 January 2008 18:49:08 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 March 2012 18:14:49 GMT