- From: <bugzilla@wiggum.w3.org>
- Date: Fri, 06 Feb 2009 18:28:14 +0000
- To: public-qt-comments@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