- From: <bugzilla@wiggum.w3.org>
- Date: Wed, 05 Apr 2006 15:32:37 +0000
- To: public-qt-comments@w3.org
- CC:
http://www.w3.org/Bugs/Public/show_bug.cgi?id=3085 ------- Comment #3 from jens.teubner@in.tum.de 2006-04-05 15:32 ------- Michael, your arguments make sense to me. With the current specification in the Formal Semantics, however, things are slightly more subtle. > For systems doing static type-checking, it's reasonable to allow them to treat > a heterogeneous sequence as an error, so that they can treat the boolean() > function effectively as polymorphic: they can decide statically which of four > different boolean() methods is being used. Right now, the FS specification uses $arg <: (empty | node+ | xs:boolean | ...) to restrict the type of fn:boolean()'s argument. This does, however, *not* mean we can infer the implementation of fn:boolean() statically. Consider the query for $x in (<a/>, 42) return fn:boolean($x). The static type of $x is (element | xs:integer), which is a valid argument to fn:boolean() according to the FS. Yet, we cannot statically decide on an implementation of fn:boolean(). Would the constraint on $arg be $arg <: empty OR $arg <: node+ OR $arg <: xs:boolean OR ... , such a decision would be possible (with positive effect on performance, at least in our case). Would that make a reasonable replacement for the static type semantics of fn:boolean()?
Received on Wednesday, 5 April 2006 15:32:47 UTC