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

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

Michael Kay wrote:

>>So, why call them variables?
>>
> 
> In a traditional mathematical formula such as
>   area = length ? breadth
> "length" and "breadth" are referred to as variables, because they can take
> different values each time you apply the formula.
> 
> The use of the word "variable" to refer to a storage location whose contents
> could be modified during the execution of an algorithm came later.
> 
> XSLT is true to the original mathematical meaning of the term.


I am sorry, folks, but I'm getting a little bit impatient
(I know you too are getting impatient with my bitching and
moaning.) But this argument "XSLT is true to the pure
mathematical meaning of 'variable'" has come up over and
over again, and it doesn't really fully convince me,
it actually turns me on, because it's pretentious.

An XSLT variable is nothing else than a label for an object
that stays constant after it's first evaluated. And that
is far, far, less than the meaning of a 'mathematical
variable'. Also, I keep hearing this contrasted to a
"storage location whose contents could be modified [by assignment
statements]", but I have not said I wanted any of this!
If you read at least the Subject line it says: "assignment
no" -- meaning I'm not asking for assignment statements.

All I'm saying is that variables in XSLT are too limited to
be really useful besides being a name for a (fixed) value
(and all of Dimitre's 4 uses of a variable that he reluctantly
recited with an apology to the others who hear that old
story again) are all the typical reasons for having a
handle to fixed objects: (1) a moderate degree of abstraction
(through term substitution), and (2,3,4) sharing and
efficiency. I'm certainly not disputing this, it's too
obvious.

My question was if the construct of an XSLT variable could
be made more useful for a broader range of situations by
allowing dynamic scoping to happen. The use cases for
dynamic scoping are well stated in the literature and
are not just my personal ideas. It seems to me that whereever
one functional/algebraic language has been designed to get
rid of dynamic binding, there was a significant movement
to bring that feature back. This happened to Scheme and
Haskell (whether the pope agrees I do not care as long as
a significant group of people who understand the issues
want it.) The "implicit parameters" paper gives a lot of
good reasons why you want dynamic binding.

Just example for short: suppose you would want an ASCII
text layouter in XSLT. It would have to deal with many
constraints and parameters such as line width and indent.
Those parameters can change as you go down into the nested
document structure (e.g., in a block-quote, in a table column,
etc.)

The only way XSLT gives you to deal with that problem is to
make *every* of those layout parameters explicit parameters
to *every* template. Even if 50% of the templates do not
care about most of the parameters, even if only 5% of the
templates intend to change the indent and text width, etc.,
*ALL* of them will have to recognize *ALL* of those
parameters and pass them on in call- and apply-templates
forms.

Now assume you figure out deep down in a special case
that you nee d to add one more parameter (e.g., text color).
You then need to rewrite the entire template library
to add text color as a parameter to every template and
make sure every template passes on that new parameter.
This is a HUGE impact of a minor change. Put this into
a distributed template development environment and library
which you can't all change and where others who do not
care about text color will concurrently maintain. It
becomes impossible.

This is where dynamic scoping is most powerful: You just
declare text color as a dynamically scoped variable and
you change only those templates that care about text
color (5% instead of 100% of the templates.)

----

I was hoping someone would listen to the arguments
and respond to them. I didn't assume I would know it all
and I repeatedly said I was ready to learn about the true
rationale why dynamic scoping is rejected. But unfortunately
the only arguments against dynamic scoping I have found in
and around the XSLT list was:

- dynamic scoping is a bad idea. period. [because I say so]

- XSLT variables are mathematical variables [and I should
   learn to overcome my simplistic imperative language
   addictions.]

- dynamic scoping interferes with functional arguments.

Of course, the only argument I can accept to work with is
the one about functional arguments (Dimitre's).

And [I don't know it, so I ask]: where exactly does XSLT have
functional arguments? I don't see a FUNARG or CLOSURE form
documented anywhere. XSLT doesn't talk about free variables
in lambda terms at all. So, I have some difficulty to see
where the functional argument issue is an issue with XSLT.
(I do realize that Dimitre has some interesting approach to
emulating some of this in his "generic template" work, which
I haven't fully grasped yet but which I find very interesting.)

In any event, I wonder: hasn't the problem of functional arguments
vis-a-vis dynamic scoping been solved in LISP long before
Common Lisp? John Allen (Anatomy of LISP) describes this
issue in 1970-something. And as far as I rememember, the
trick was simply to pack the current environment with the
funarg at the time it is created. Then you can pass it
around such that the free variables in the lambda term are
bound to a constant value that was that variable's value at
the time the funarg was created. What's wrong with this?

regards,
-Gunther



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