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

[Gunther Schadow <gunther at aurora dot regenstrief dot org>]

Hi,

On my earlier wish list for a future XSLT some interesting threads
spun off. One of them is the issue of variables.

Andrew Welch wrote:


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


and Dimitre Novatchev responded:


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

> any declarative programming language.


...


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?

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
a global variable (outside of a template) that variable's value
can not be reassigned, which is O.K. with me. But it can not be
overridden either, except if it is in the lexical scope. So, I
conclude that variable could have been named constant (still holding
on to the parameter for passing along dynamic bindings.)

The only use of variables I have encountered within a template are
for (1) term substitutions which make a complex Xpath expression somewhat
easier to read and (2) to capture result tree fragments. Again, these
are nothing else than lexically scoped constants.

So, why call them variables?

But it would all suddenly make sense if those variables would be
dynamically scoped! So, that's another wish for a future XSLT.
With dynamic scoping you had an easy answer to those who ask for
"how do I assign variables": you put new bindings into the Weizenbaum
environment along the template call graphs, which are gone once the
call graph unravels. That's the usefulness of a global symbol
without the evils of side effects. That would be a hell of a useful
feature. Ah the joys of LISP :-).

I suppose one could construct an environment in the form of
a nodeset and make all of one's own templates pass that
environment on, always, whether they need it or not. That
would emulate dynamic binding. However, that would make code
reuse between different developers very hard, and, explain
*this* to your "web developer" :-)

I think the issue with modes that I have is similar. I guess what
I want is mode to be such a dynamic context, such that once I
switch mode in an explicit apply-templates call, all the other
apply-templates in the call-graph down from there should use the
same mode until overridden. This would almost get rid of the need
to construct modes.

regards
-Gunther


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?
-- 
Gunther Schadow, M.D., Ph.D.                    gschadow@regenstrief.org
Medical Information Scientist      Regenstrief Institute for Health Care
Adjunct Assistant Professor        Indiana University School of Medicine
tel:1(317)630-7960                         http://aurora.regenstrief.org



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