This is aggressively tested in every instance where it could be affected,
since any mishandling of this value would be incredibly dangerous (best
case, it would blow up and abort; worst case, data are interchanged between
refs).
This produces a short-hand partial application (well, it'd be more accurate
to call the use of `f:apply' or `f:partial' long-hand, since this is most
natural).
This is intended as a convenient shorthand:
```xml
<!-- these two are identical -->
<sequence select="f:apply( my:func(), $x, $y )" />
<sequence select="my:func( $x, $y )" />
```
As operations on dynamic function references become more complex, and since
evolution of the reference structure is planned to evolve, maintaining an
abstraction is vital for both grokking and maintenance.
Previously, a separate `@partial' attribute was added to the ref and the
`@arity' maintained. Unfortunately, this coupled `f:arity' with
`f:partial', which is unnecessary, considering that partial application is
supposed to conceptually yield a new function, which should be transparent
to `f:arity'.
This introduces support for partial applications on dynamic functions.
The test cases are comprehensive and the implementation should be
quite stable.
Even though the base higher-order function implementation was based on
the work of Dimitre Novatchev[0], I have chosen a different route for
partial application: Novatchev's method relies on storing partially
applied arguments as nodes, together with their types. The types are
detected the best they can be, with accuracy varying wildly depending
on whether a schema-aware processor is present.
But regardless, that method would not retain node context.
Sequences, however, do. By using sequences, we allow the processor to
retain all type and context information perfectly without any
additional work that is inaccurate, adds complexity, and likely to
cause subtle problems. It will also support any types that we are
unaware of. As Novatchev mentions:
The argument type-detection that f:curry() uses has been implemented
only for the builtin XML Schema datatypes. It will not recognize the
user-defined type of an argument, which can be created by an user of
a Schema-Aware (SA) XSLT 2.0 processor.[0]
This is not a problem with hoxsl.
[0]: http://conferences.idealliance.org/extreme/html/2006/Novatchev01/EML2006Novatchev01.html
I am aware of the Saxon 9 warning regarding multiple imports of arity.xsl;
I'm going to choose to ignore this, formally in the future. Each of the
stylesheets is treated like a module.
Michael Kay, Saxon's author, discusses it here:
http://stackoverflow.com/a/10102298
Mike Gerwitz