The FP idiom, sporting lazily and readily optimizable computation, suggests
that functions can be forced to produce a result (i.e. actually calculate
something) only when the result is needed for some ultimate calculation.
This is achieved thru side-effect-free realization of functions. Given
this, then a side-effect-free aware functional optimizer can execute
"stuff" in any order (so long as the computations have no side-effects).
Somehow, the notion of calculation, in an FP sense, sublimes time and
therefore ordering of output.
Now, the FP alphabet of functions includes as its signature functions,
"map", "fold" (aka "reduce") and so on.
However "so on" rarely includes "foreach" as a signature function of the FP
idiom. Is this because "foreach" implies some kind of time ordered
calculation, and therefore not optimizable?
Noting that xsl:foreach always produces the same ordered output (in a
result document), does this imply that XSLT breaches the pure FP idiom,
recognizing, of course, that XSLT has never claimed to be an FP language?
Perhaps I've been eating too much monadic fungi, but there seems to be a
something about the essence of "foreach" as opposed to, say, map, in an FP
context that needs explanation.
Whatever the explanation, it still seems difficult to me to say what the
heck of a kind of a language XSLT actually is :-)
P.S. Dimitre, thanks for your response on a prior thread :-
> The woe for me however is having to counter the screams I'll no doubt get
> converting indexes on the external library side
This is the least problem you might have. Be ready to explain why an
xsl:variable cannot be modified... :)