RE: No convenient way to cast one expression to the same type as another?

It's a question of how difficult the function is for users to implement, and 
how convenient the syntax is.  Paths could all be FLWOR statements, but no one 
seriously suggests cutting paths.

I'm merely pointing out that in certain situations, XQuery is tantalizingly 
close to being able to implement complex operators, but then fails to go that 
last 10%.

In previous versions of the drafts, operators like = were easily expressed in 
terms of other built-in operators:

define function my:equals($lhs, $rhs) {
  some $i in $lhs, $j in $rhs
  return $i eq $j
}

Now they're much more complex.  I can express their entire semantics, except 
the one rule that says "cast one operand to the same type as the other 
operand" -- which seems like something that users will need to do themselves 
in their own user-defined functions.

If it's not useful, then why do the built-in operators do it?  If it is 
useful, why prevent users from doing it?

Another example is the lack of an "order by document order" expression, which 
comes up all over the drafts (although this can be done using ($expr)/. if you 
don't mind losing duplicates, so it's not a significant loss).

I think the rules behind built-in language features are often representative 
of the rules users will need for their own extensions (especially if they're 
trying to emulate the built-in features).

(I also think these operations could be provided without going all the way to 
second-order functions and type introspection.  Indeed, they're already part 
of the language semantics, just not its syntax.)
> > Hmm, then this is a place where XQuery defines semantics that 
> > cannot be expressed using XQuery.
> 
> But we have in the past used the argument that if a function can be
> implemented by the user, then we shouldn't be providing it in the core!
> 
> I'm not sure I follow your reasoning. We have consciously decided not to
> support either types or functions as first-class objects in the data model
> in this version of the specification. This inevitably means that there are
> functions and operators in the core that the user could not write for
> themselves.
> 
> Michael Kay
>

Received on Tuesday, 10 June 2003 12:08:30 UTC