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

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

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
http://aurora.regenstrief.org



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


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