I've been thinking about this more. I'm starting to drink the koolaid of
the "XQuery Way".
Where is the real confusion/hardship of the current syntax rules for {} ?
Ignoring if/switch etc which is more then just omitting expression (it makes
ambiguities about where else's go in nested if/elses) and just focus on {}
== {()}
Where in practice is that really a hardship ?
I am now convinced it comes down to comments really ... and only comments in
element constructors.
<foo>{ () (: comment :) }</foo>
Vs
<foo>{ (: comment :) }</foo>
Or
Element {"foo"} { (:comment :) }
Is just pretty contorted IMHO ... but it is *consistent* and once you learn
it its not a problem.
You don't have this problem in most places where you put comments like
If( expr ) (: true :) fn:true() else (:false:) fn:false()
The other cases where {} => {()} would be useful are not so vastly ugly the
way they are now.
So I'm coming over to the mindset that this is something that's better
living with then changing.
----------------------------------------
David A. Lee
[email protected]
http://www.xmlsh.org
From: [email protected] [mailto:[email protected]] On Behalf
Of Henry Luo
Sent: Sunday, December 04, 2011 8:17 AM
To: [email protected]
Subject: Re: [xquery-talk] why must one have something inside {} ?
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
