Bug 11792 - lack of syntactic symmetry between the control flow expressions
lack of syntactic symmetry between the control flow expressions
Status: RESOLVED WONTFIX
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: XQuery 3.0
Member-only Editors Drafts
PC All
: P2 normal
: ---
Assigned To: Jonathan Robie
Mailing list for public feedback on specs from XSL and XML Query WGs
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-01-18 16:39 UTC by Daniela Florescu
Modified: 2011-04-26 16:41 UTC (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Daniela Florescu 2011-01-18 16:39:51 UTC
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
Comment 1 Michael Kay 2011-01-18 17:28:39 UTC
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.
Comment 2 Daniela Florescu 2011-01-18 17:56:59 UTC
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.
Comment 3 Jonathan Robie 2011-04-26 16:41:50 UTC
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