RE: IfExpr has a mandatory else clause

You could simply use parentheses to tie the 'else' to the outer 'if':

if (expr) then (if (expr) A) else B

Bas de Bakker
X-Hive Corporation

> -----Original Message-----
> From: www-ql-request@w3.org [mailto:www-ql-request@w3.org]On Behalf Of
> TAN Kuan Hui
> Sent: Monday, January 26, 2004 10:14
> To: Michael Dyck; www-ql@w3.org
> Subject: Re: IfExpr has a mandatory else clause
> 
> 
> 
> 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 "}")?
> 
> where 
>     <"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:26:05 UTC