[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: Assignment no, dynamic scoping si (was: Re: RE: Wi

Subject: RE: Assignment no, dynamic scoping si (was: Re: RE: Wishes for XSL revisions ...
From: "Michael Kay" <michael.h.kay@xxxxxxxxxxxx>
Date: Wed, 2 Jan 2002 11:48:26 -0000
xslt variable values reassignment
> 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.

Sorry I misunderstood your question. I now see what you're getting at. As
far as I'm aware, the XSL Working Group has never considered adding dynamic
scoping of variables, by which I'm saying (a) no-one has raised it as a
high-priority requirement, and (b) no-one has said it's a bad idea and
contrary to the design principles of the language. I'd suggest you construct
a proposal, supported by use cases, and send it the the xsl-editors list.
Your big challenge, I suspect, will be convincing the WG that it solves a
serious problem that can't already be solved in some other way. If you want
it considered seriously for inclusion in 2.0, you'll have to demonstrate
that it provides a good solution to one or more of the published 2.0

Mike Kay

> 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@xxxxxxxxxxxxxxx
> Medical Information Scientist      Regenstrief Institute for
> Health Care
> Adjunct Assistant Professor        Indiana University School
> of Medicine
> tel:1(317)630-7960

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

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

Current Thread


Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
First Name
Last Name
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.