Michael Kay

>Would `has()` work better than `get()` I wonder? Feels too much like something that returns a boolean.

>fn:jnode-selector is both very technical and counterintuitive. Couldn't we rename it to fn:key? `fn:key` is taken (since XSLT 1.0). I would love a shorter name, we could certainly reduce it...

>What if we simply extend the lookup expression so that if it is applied to an XNode, it returns an XNode ? Did you mean JNode? I don't think that...

I'm sorry, I'm having trouble following the thread and working out what your preferred proposal is.

Possible variant: rather than compiling an XPath expression, the function should compile an XPath anonymous function declaration, and return a function item corresponding to that anonymous function?

>shouldn’t it be pretty fast to compute a hash key for a query string? It's not the query string that's the problem, it's the static context: in the case of...

>It seems that the function needs an extra parameter $parameter-map I think it would be neat if you could do `let $f := compile-function("fn($x, $y) { $x + $y }")`...

I'm not convinced. `$one[not(. = $two)]` `values-except($one, $two)` The former is shorter, to my mind it's just as readable, and just as optimizable. It also doesn't have unexpected side-effects of...

In Saxon-EE we optimize general comparison equijoins (such as `$x[. = $y]`) but not non-equijoins (such as `$x[not(. = $y)]`). The general policy is to add optimizations when we see...

I've said many times and I will say again: the difficult part in all of this is defining and parameterizing how equality matching works across the type system. Once we've...