W3C home > Mailing lists > Public > www-ql@w3.org > January to March 2004

Re: IfExpr has a mandatory else clause

From: TAN Kuan Hui <kuanhui@xemantics.com>
Date: Mon, 26 Jan 2004 17:14:26 +0800
Message-ID: <001001c3e3ec$cf3f1230$4445bada@pinecone>
To: "Michael Dyck" <jmdyck@ibiblio.org>, <www-ql@w3.org>

From: "Michael Dyck" <jmdyck@ibiblio.org>
> How would you resolve the ambiguity?
I would bias towards interpreting "else" rather than reducing
(<"if" "("> Expr ")" "then" ExprSingle) to IfExpr in the presence
of "else". This is the "classic" approach isn't it ?

This however implicitly ties the else clause to the innermost if clause.
The lack of explicit statement block markers in the grammar
however makes the coding of nested conditional expressions
with optional "else" tricky; but this is not due to the
introduction of an optional else clause but the lack of
block structure in the grammar. I would propose the IfExpr 
to be re-written as,

[54]    IfExpr    ::=    <"if" "("> Expr ")" "then" "{" ExprSingle "}"
(<"else" "{"> ExprSingle "}")?

    <"else" "{"> calls pushState(DEFAULT);

Note :
1. There is no ambiguity with the optional "else" clause; however
note that introducing statement blocks elsewhere in ExprSingle may
bring back the ambiguity but it can be distinguished.
2. The statement block delimited by {} removes ambiguity 
for nested if-else expressions and makes the logical 
structure much cleaner and is consistent with the usage
of {} for the grouping of functionalities (as with function 
declaration). Thus I think the introduction of {} in the
IfExpr should be fairly intuitive.
3. There is no impact on the rest of the XQuery grammar.
4. There is also no conflict with NCName.

Are there other ambiguities that I have not considered ?
Received on Monday, 26 January 2004 04:14:18 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:17:16 UTC