[xsl] RE: Wishes for XSL revisions ...

Subject: [xsl] RE: Wishes for XSL revisions ...
From: Dimitre Novatchev <dnovatchev@xxxxxxxxx>
Date: Thu, 27 Dec 2001 05:52:07 -0800 (PST)
> >I'm not sure that was right - looking at the questions on this list it
> >seems to be the programmers who are most easily confused.  Top of the
> >list seems to be variables whose value cannot be changed and for loops
> >which aren't.
> >
> >Regards,
> >Trevor Nash
> I think the answer is in that statement.  I have two points:
> 1.  Is there ever a good time to use a for-each? From reading this list for
> a while these seem to be the root of most problems and are very rarely
> included in any solutions... are they really necessary? (Ive read in places
> they were intended to make the language easier to learn for beginners!)

  One example when using xsl:for-each is necessary is when the current document
needs to be changed so that the key() function can be used on it. Look for an
example at:


> 2.  If a variable cannot be changed after it has been assigned, why call it
> a variable?  Ive read the reasoning behind this, and yes strictly it is a
> variable, but a more appropriate name would make sense.
> The above makes XSLT non-intuitive, and therefore harder to learn.  Is there
> another language where you cannot change the value of a variable?

Lot's of languages -- e.g. any functional progaramming language or any declarative
programming language.

Yet another language is the language of mathematics, from which the term "variable"

A "variable" is used in mathematics to help capture/express some existing
relationship/law. As such it cannot be arbitrarily altered. For example:

x = x + 1 

is never true for any x.

If z is defined as:

z = x * y

it would be dangerous and generally incorrect to change the value of z (or of x or
y), as this will generally break the above law (equation).

Imperative programming languages are based on the understanding that a system is
modelled as having a state and evolving from an initial state to a set of final
states. A variable is a store for a (component of a) state. As the state of the
system changes, so do the values of the variables, which together constitute the
state. This incorrect association of a variable with a store is typical for the
imperative programming model.

A very narrow context (,insufficient maths background and not knowing anything else
than the imperative programming model), will always produce incorrect understanding
of what a variable really is.

Hope this helped.

Dimitre Novatchev.

Do You Yahoo!?
Send your FREE holiday greetings online!

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

Current Thread