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
|