[XSL-LIST Mailing List Archive Home] [By Thread] [By Date]

[xsl] Re: Assignment no, dynamic scoping si (was: Re: RE: Wishes for XSL revisions ...


Subject: [xsl] Re: Assignment no, dynamic scoping si (was: Re: RE: Wishes for XSL revisions ...
From: Dimitre Novatchev <dnovatchev@xxxxxxxxx>
Date: Thu, 27 Dec 2001 23:51:48 -0800 (PST)

Gunther Schadow <gunther at aurora dot regenstrief dot org> wrote:
> I have wondered about this variable issue as well and it seems to
> me that the current XSLT design is a bad combination of a block-
> structured imperative language with lexical scoping and a lofty
> notion of a non-assignable variable. Not speaking about the
> parameters (arguments.) With arguments lexical scoping is bearable
> you just have to pass them on (and hope that there are no templates
> on the apply-templates path that do not know about those arguments
> and hence don't pass them on. However, what purpose is the
> XSLT variable?

In case XSLT is such a bad language to you, what are you doing here in this XSLT
list? Would you frequent a Cobol list and tell them how bad their language is?

One alternative is to switch to a better functional language (e.g. Haskell), use
HaXML and forget about XSLT. This however will likely not appeal to you as Haskell's
variables are immutable too...

> I'm certainly not the genious that Dimitre is, but for all I can
>see, the only use right now is as a constant! When someone declares

Hardly anybody on this list is a genius, but a little more reading will not hurt.

> PS: may be Dimitre or someone else can calm my mood by recalling
> for me in what way the usually statically scoped Scheme language
> is superior over dynamically scoped LISP? Or what makes a variable
> that can only be overridden in a lexical scope different from a
> local constant?

The best recommendation for anybody asking such basic questions is to read the good
books. Somebody already mentioned Mike Kay's book. There are two good books on
Haskell:

Simon Thompson's "Haskell The Craft of Functional Programming"

and 

Paul Hudak's "The Haskell School of Expression".

Thompson's book has a small, nice appendix comparing functional, imperative and OO
programming. Allowing changes of the value of a variable makes imperative languages
not side effects free. This makes it very difficult or almost impossible to perform
program verification and program transformation. Another general result of
imperative languages not being side effects free is that they are much more
difficult to maintain than side effects free languages. Some nice features, as for
example lazy evaluation, do not fit well languages with side effects.


Cheers,
Dimitre Novatchev.

__________________________________________________
Do You Yahoo!?
Send your FREE holiday greetings online!
http://greetings.yahoo.com

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



Current Thread
Keywords