When I first tried to implement XQuery support , I also wondered why
XQuery does not allow empty function body, and why if expr must have an
else branch, and why switch must have a default branch. Programmers from
procedural world are likely to ask these questions when they first
encounter XQuery. In procedural world, we are used to the convention
that no-op is a valid operation, and we have tons of functions that
return void.
But in XQuery, the syntactic convention has been that *empty value must
be stated explicitly*. It's a convention that has been consistently
applied to language constructs like:
- enclosed expression: { () }
- function body: function name() { () } (: such function
might only be useful in debugging, but pretty useless in production :)
- element/node constructor: element {()} {()}
- if and switch expr: if (expr) then expr else () (: else branch is
required, even if it is empty value :)
The major advantage of this convention, as Michael Kay suggested, is
that stronger diagnostics can be performed as users are forced to be
more explicit about what they want. And I don't think future versions of
XQuery will switch to the other convention to allow empty value to be
omitted in these cases.
In XSLT and Candle (http://candlescript.org) statement syntax, however,
the convention is to *allow empty value to be omitted*. The advantage of
this convention is of course simpler syntax.
There's no right or wrong here. No convention is best in all use cases.
And we'll just have to know the conventions and get used to them.
Henry
On 4/12/2011 7:37 PM, Michael Kay wrote:
On 03/12/2011 23:27, David Lee wrote:
I'm not suggesting "{}" is a 'no-op' I'm suggesting it parses
equivalent to
{()}
Maybe in the next week or two I'll study the BNF in more detail and
make a
formal suggestion as per Liam's suggestion for XQuery 3.0
So far I haven't seen any reason why it would be either
1) Ambiguous
2) Cause parser confusion
3) Cause reader confusion
4) Cause 'unexpected' things to happen
There are other objections the WG might want to consider: Assigning a
meaning to constructs that are currently disallowed
(a) can make it more difficult to produce good diagnostics for queries
that are actually wrong (ultimately, you end up with the HTML5
situation where everything you write means something, so there are no
compile-time errors, only run-time errors), and
(b) can "use up" syntactic space that might be needed in the future
for new features. For example, one might want "{}" to represent an
empty map - which is not necessarily inconsistent with this proposal,
but in general, when you give a syntactic construct a meaning you
remove the option of giving it a different meaning in the future.
Michael Kay
Saxonica
_______________________________________________
[email protected]
http://x-query.com/mailman/listinfo/talk
_______________________________________________
[email protected]
http://x-query.com/mailman/listinfo/talk
