Saxon » SaxonJS

Looking at the SEF trees resulting from the XPath parsing of the two expressions, the only significant difference is that with explicit function call, the inferred type of the second argument of the anonymous inline function is 1E (a single element node, element(*)) whereas with the arrow operator the inferred type is 1NE u[NE u[NE u[NE nQ{}a,NE nQ{}c],NE nQ{}b],NE nQ{}b], that is a union of elements a, c, b, and b.

Although this type inference appears to be correct, it's surprisingly ambitious. At some subsequent stage it seems to have been replaced by xs:empty (the type with no instances), and after this incorrect substitution, the call supplying element a is inevitably rejected.

It's rather suprising (a) that the type inference should be so ambitious, and (b) that it should differ between the two ways of writing the function call. It's less surprising (although still of concern) that things then go wrong subsequently.

Looking at the parseFast / parseFunctionCall() code, which handles the lexical parsing of both conventional function calls and arrow expressions, mixed in with it is some special-case type inferencing logic for specific higher order functions (fold-left, fold-right, filter, for-each). I've no idea why this is needed and this certainly doesn't seem to be the right place for it.

But apart from that, it contains a simple bug: the loop at line 3129 is only processing the explicit arguments (within the parentheses), it's not processing the implicit argument that precedes the arrow operator

The code in parseFunctionCall (which treats well-known higher-order functions specially) is setting the expected types of the inline function argument (if there is one!) in an array inlineFunctionArgTypes which is used while parsing the inline function to supply defaults for the parameter types. But this is hopelessly flawed because inlineFunctionArgTypes is a parser-level variable and there's no provision for inline functions being nested.

My suspicion is that the whole mechanism could come out without problems; after all, we have to handle dynamic calls on these functions where nothing is known in advance.

I've experimented with disabling the mechanism, and it seems to have no adverse effect on QT3 results.

If we do want to be smarter about the static type-checking of these cases I think there are two proper ways it could be done. (a) we could do the type refinement as a separate pass over the expression tree, as SaxonJ does, or (b) we could pass expectedType as an additional argument through the recursive parseXXX() function calls. But the benefits are questionable.

I think I'm going to take this code out.