Re: Re: Reference to variable cannot be resolved.

"Michael Kay" <michael.h.kay@xxxxxxxxxxxx> wrote in message
news:001301c2d4cb$f590eac0$6401a8c0@xxxxxxxxxx
> > 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.


=====
Cheers,

Dimitre Novatchev.
http://fxsl.sourceforge.net/ -- the home of FXSL




 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list