Subject: RE: Assignment no, dynamic scoping si (was: Re: [xsl] RE: Wishes for XSL revisions ... From: "Michael Kay" <michael.h.kay@xxxxxxxxxxxx> Date: Wed, 2 Jan 2002 11:48:26 -0000 |
> 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
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: Assignment no, dynamic scoping , David Carlisle | Thread | Re: Assignment no, dynamic scoping , Terje Norderhaug |
Re: [xsl] Re: XPath incompatibiliti, Jeni Tennison | Date | RE: [xsl] result = node1 * node2 an, Michael Kay |
Month |