An interesting proposal; I'd say it is certainly worth examinely more
closely.
On first reading, I have few issues/questions.
Import name conflicts for subfunctions. Libraries of subfunctions
may easily contain duplicate function names. Do we allow this (with
some sort of rule about which subfunction wins), ban it
(deployment-time error), or have a way of distinguishing (qualifying)
the names?
Cannot the word 'host' be replaced by term "caller's scope"?
Given the demands of serializable scopes (and the need to
statically determine read and write behaviour of a scope), would it not
be helpful to allow a sub-function to declare if an input parameter
were "read-only" or "read/write"? This would free the sub-function from
the restrictions placed on expressions to permit such static analysis.
XPath is supposed to be side-effect free, which implies (to me,
at least) that variables passed as parameters (by reference, of course)
must be read-only.
If we do allow side-effects in XPath-callable functions, we might
need to worry about XPath order-of-evaluation, as well as
short-circuiting of logical expression evaluation, in order to assure
portable behaviour. I don't believe XPath 1.0 specifies these things.
I assume that a <function> activity would be a basic
activity, so that <subfunction> activities could not contain
start activities?
Let me mull your proposal over a bit more; perhaps I can answer some of
my own issues.
Cheers,
-Ron
