- From: TAN Kuan Hui <kuanhui@xemantics.com>
- Date: Mon, 26 Jan 2004 17:49:37 +0800
- To: "Bas de Bakker" <bas@x-hive.com>, <www-ql@w3.org>
Syntactically seems to parse but will this cause confusion ? Using () instead of {} will also re-introduce the ambiguity with an optional else clause although distinguishable. So is grammar ambiguity the reason that IfExpr has a mandatory else clause ? Are there other design considerations ? Appreciate any clarification. ----- Original Message ----- From: "Bas de Bakker" <bas@x-hive.com> To: "TAN Kuan Hui" <kuanhui@xemantics.com>; <www-ql@w3.org> Sent: Monday, January 26, 2004 5:22 PM Subject: 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:49:31 UTC