This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Dear all, please look at the syntax of three of the control flow expressions that are available in XQuery 3.0, that look very similar in functionality and structure, but slightly dissimilar in grammar. Those are switch, typeswitch and try catch. The (simplified) grammar is bellow: ---------- 'typeswitch' '(' Expr ')' ( 'case' ( VarName 'as' ) ? SequenceType 'return' Expr )+ 'default' VarName ? 'return' Expr 'switch' '(' Expr ')' ( 'case' Expr 'return' Expr ) + 'default' 'return' Expr 'try' '{' Expr '}' ( 'catch' CatchErrorList CatchVars? '{' Expr '}' )+ ---------- Each one of them has: (a) a main expression to evaluate and (b) several branches, one of them being evaluated and the result being returned, the choice being based on the presence of some particular events: a certain type, a certain value or a certain error. And they are all three expressions, all three of them returning instances of XDM. Let's look at examples of each of them. typeswitch ( $x div $y ) case xs:integer return "First branch" case xs:decimal return "Second branch" default "Last branch" switch ( $x div $y ) case 3 return "First branch" case 4 return "Second branch" default "Last branch" try { $x div $y } catch err:FOAR0001 { "First branch" } catch err:FOAR0003 { "Second branch" } catch * { "Last branch" } The lack of syntactical similarity and symmetry between them is very difficult for a user (I can never remember what to use where..). The two major differences are: (a) the use of () vs. {} in switch/typeswitch vs. trycatch for the main Expr to be evaluated (b) the use of the keyword 'return' vs the use of {} in in switch/typeswitch vs. trycatch for the Expr to be returned There is no reason for those syntactic differences. Users can only be confused by that. Could we please make them grammatically symmetrical ? Best regards Dana
Tricky - changing either switch or try/catch to be more like the other will at the same time make it less like the equivalent construct in the C/Java family of languages. The parentheses-versus-curlies problem in XQuery is very real. I've never understood why validate{} isn't a validate() function, and the distinction between unordered{} and unordered() is so subtle I doubt many WG members could explain it without first checking the spec (especially as no-one ever uses either...). Unfortunately, I think it's too late to fix this, and it's hard to see how to add new constructs without perpetuating the arbitrariness of it all. Certainly, changing try() to use parenthesis rather than curlies would make it more like some things and less like others, without giving any overall improvement in consistency.
Mike, that would be the right solution in my mind: make the trycatch look like switch and typeswitch. try ( Expr ) ( catch Qname return Expr )+ I agree with you that we made this mistake in the past (unordered and validate are examples, indeed). But really we shouldn't do it again. Plus the use of {..} and the lack of 'return' will push people into believing that what follows, or what is enclosed, is a statement, while it is not. They are plain expressions like the other ones. Best regards Dana (In reply to comment #1) > Tricky - changing either switch or try/catch to be more like the other will at > the same time make it less like the equivalent construct in the C/Java family > of languages. > > The parentheses-versus-curlies problem in XQuery is very real. I've never > understood why validate{} isn't a validate() function, and the distinction > between unordered{} and unordered() is so subtle I doubt many WG members could > explain it without first checking the spec (especially as no-one ever uses > either...). Unfortunately, I think it's too late to fix this, and it's hard to > see how to add new constructs without perpetuating the arbitrariness of it all. > Certainly, changing try() to use parenthesis rather than curlies would make it > more like some things and less like others, without giving any overall > improvement in consistency.
In today's telcon, we did not achieve consensus to change the bracket conventions. We did achieve consensus to eliminate the CatchVars as follows: CatchClause ::= "catch" CatchErrorList CatchVars? "{" Expr "}" => CatchClause ::= "catch" CatchErrorList "{" Expr "}" Implicitly define these variables within the scope of a catch clause: $err:code $err:description $err:value Also implicitly define these variables within the scope of a catch clause - implementations that do not provide a value for these variables must bind them to the empty sequence: $err:module $err:line-number $err:column-number These variables have the same meaning as in XSLT - see http://www.w3.org/XML/Group/qtspecs/specifications/xslt-30/html/Overview-diff.html#try-catch