W3C home > Mailing lists > Public > public-qt-comments@w3.org > February 2009

[Bug 5332] [UPD] Parentheses around () or fn:error()

From: <bugzilla@wiggum.w3.org>
Date: Fri, 06 Feb 2009 18:28:14 +0000
To: public-qt-comments@w3.org
Message-Id: <E1LVVR0-0007c4-6C@wiggum.w3.org>

http://www.w3.org/Bugs/Public/show_bug.cgi?id=5332





--- Comment #9 from Michael Kay <mike@saxonica.com>  2009-02-06 18:28:13 ---
1. I agree that the definition could be tightened. I would suggest:

[Definition: Various expressions are defined in this specification to be
vacuous: examples are <code>()</code>, <code>fn:error()</code>, and <code>if
(x) then () else ()</code>. When evaluated, a vacuous expression will either
return an empty sequence or raise an error. The analysis to determine whether
an expression is vacuous is done statically.]

2. My understanding is that the WG rejected my original proposal to allow
processors flexibility to decide that expressions such as "if (true()) then ()
else 3" were vacuous, preferring instead to define a simple set of
interoperable rules. I don't see any reason for reopening that question.

3. No-one is ever going to deliberately write a function that always returns ()
or throws an error, so there seems no point at all in defining a keyword to
allow such functions to be labelled. One could extend the rules so that a
function call is vacuous if the body of the function being called is vacuous;
but that seems an unlikely scenario, and it's hard to define the rule without
risking circularity if the function is recursive.


-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
Received on Friday, 6 February 2009 18:28:24 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:57:26 UTC