Subject: Re: Assignment no, dynamic scoping si (was: Re: [xsl] RE: Wishes for XSL revisions ... From: Gunther Schadow <gunther@xxxxxxxxxxxxxxxxxxxxxx> Date: Mon, 31 Dec 2001 12:08:31 -0500 |
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:
- XSLT variables are mathematical variables [and I should learn to overcome my simplistic imperative language addictions.]
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@xxxxxxxxxxxxxxx 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
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
RE: Assignment no, dynamic scoping , Michael Kay | Thread | [xsl] Re: Wishes for XSL revisions , Dimitre Novatchev |
RE: [xsl] Substituting XSL Variable, Michael Kay | Date | [xsl] Re: Assignment no, dynamic sc, Dimitre Novatchev |
Month |