"Michael Kay" <michael(_dot_)h(_dot_)kay(_at_)ntlworld(_dot_)com> wrote in
I think the biggest problem here is that the scope of a
variable is no longer obvious in these cases. This will also
impose an (hidden) order of evaluation, which is not the most
desirable feature for a non-imperative language.
The second sentence is nonsense. Variable references are resolved to
variable declarations at compile time, the run-time behavior doesn't
care in the slightest what the original name of the variable was.
The second sentence does not say anything about run-time behaviour. What it
says is that a variable declaration that "shadows" a sibling and also uses
it in its definition must be evaluated after the shadowed sibling is
evaluated. Of course, this is decided even at compile-time.
This is natural, if there was no shadowing and at the same time referencing
the shadowed variable, which at the same time is in the same lexical scope.
To summarise, when using this "feature", it may become a challenge to infer
the order of evaluation of a sequence of siblings. one will have to mark it
with a pencil on a printout of the stylesheet.
Then, even a slight re-ordering of some siblings may have dramatic effects
on the results of the transformation.
http://fxsl.sourceforge.net/ -- the home of FXSL
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list