RE: Re: Re: Reference to variable cannot be resolved.

> 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.

What I'm saying is that at run-time, there is no difference between
evaluating

<xsl:variable name="y" select="2"/>
<xsl:variable name="x" select="$y+2"/>

and

<xsl:variable name="x" select="2"/>
<xsl:variable name="x" select="$x+2"/>

The second variable can't be evaluated until after the first one is
evaluated in either of these cases; allowing the two variables to have
the same name makes no difference to the constraints on order of
evaluation.

Michael Kay
Software AG
home: Michael.H.Kay@xxxxxxxxxxxx
work: Michael.Kay@xxxxxxxxxxxxxx 



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