Subject: Re: [xsl] Re: Re: Assignment no, dynamic scoping si (was: Re: RE: Wishes for XSL revisions ... From: Gunther Schadow <gunther@xxxxxxxxxxxxxxxxxxxxxx> Date: Wed, 02 Jan 2002 16:40:27 -0500 |
Certainly. This is very simple using XSLT. You even don't have to modify the "section" template neither do you need a global variable. In the "paragraph" template declare and use the following local variable:
<xsl:variable name="source" select="ancestor::section[1]/@source"/>
Ouch, I knew you were going to pick this. It works because I am simplifying my examples. But your approach to this seems to be a-priori denial of any use for my request (even though it's documented elsewhere in the literature) and then you pick the weaknesses of the example to prove the use case non- substantial. Well, if I were as opposed to this as you are, I would probably do the same. So, let's drag this out another round :-)
Your solution works in this case because the source attribute is *provided*. If it were *computed* from a variety of other data you could not do that, or at least you would have to repeat the computation whereever you want to access the value. According to your own statements, Dimitre, the use of a variable is in reducing redundant computations of the same value.
So, let's say I need a 'text-indent' value for use in a plain-text formatter. The value of text indent is calculated from the cureent indent + an increment that depends on the element. The template that emits one line of text has no clue about the algorithm to derive the text-indent from the structure of the document, that's what the other templates for the other elements are for.
Or let's say we have 'text-color', that is computed from all kinds of circumstances, with the logic of computing this being coded locally in the template that handles the given element.
In my proposal (submitted under Request for ...) and in this example, however, you see that implicit parameters are declared just as explicit parameters in their lexical scope. So you know exactly what they are (of course their actual binding will be dynamic.)
If there were any type checking with XSLT (say, if XSLT were a strongly typed language) the type would be mentioned in the declaration everywhere and could be validated throughout the stylesheet at compile-time. So it's safe.
Type-checking many descendents of a node in a tree is much more
difficult than type-checking the formal/actual types in a direct
call/instantiation (which is just a segment compared to the tree
in the former case). As Mike mentioned, most probably this would
be prohibitively more costly than the added value the feature
proposed by you may bring.
Because this feature is structurally just like parameters, meaning there is no other way of declaring the type of an implicit parameter or binding a value to implicit parameters than to explicit parameters, why should it be any harder to implement type checking? You can do type checking just as in statically scoped variables and parameters, there's no difference.
I'm still not sure how that is a problem with XSLT, because XSLT doesn't do type checking to parameters either, but I'll follow your thought nevertheless (which is what I would expect from you too.)
Well, O.K. as I'm working with your concern (the way I expect you to work with mine), I find that since the call graph is usually not known statically (can be done to an extent, but most compilers don't) you will not be able to check for which type is passed to an implicit parameter in every case. Since you don't know who calls whom eventually, you will have to make some simplification. For example, substituting a specialization to a formal parameter of a generalization type will be a problem because the two templates could have been called in the reverse order (through intermediaries) at which point a generalization would be substituted for its specialization, which would be invalid. The solution would be to require all of the implicit parameters to be of an identical type.
Of course this is only a concern if you actually do compile time type checking and if you cannot afford run time type checking. Which one is used in XSLT? Isn't it run time type checking? In that case there is no problem.
It's so easy to implement. Just do shallow binding, associate a stack of values with the name as an implicit parameter. Then as you encounter a new binding, push it onto that stack. As you leave a frame that has made such fluid binding pop it from the stack. To denote an implicit parameter get it from the top of the stack. If the type of the value doesn't conform to the declaration of the implicit parameter (where would a type declaration happen in XSLT?) you would throw an exception. For statically provable correctness just do not allow gen/spec substitution. If you find shallow binding too burdensome, do some deep binding of all implicit parameters on one association list. That's even easier especially when dealing with functional arguments (which don't exist in XSLT either.)
Actually, until now you haven't been
able to provide a single example, where such added value is
apparent.
You have been given three forms of this use case plus reference to the literature (implicit parameter paper). But so far you're approach to the argument has been to reduce everything that does not support your point of view to it's nearest convenient flaw to shrug it off. You did that with what I said, what Terje said, you even did it with the implicit parameter paper. It's not exactly a gratifying experience to discuss with you. Am I ad hominem? Frustrated, yes, may be I should pause a bit. I moved this to xsl-editors anyway, and the response I got so far is not as frustrating. Interestingly I learned that the dynamic scope issue had never come up in the past, so it isn't pre-decided in any way.
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 -> |
---|---|---|
[xsl] Re: Re: Assignment no, dynami, Dimitre Novatchev | Thread | RE: [xsl] Re: Re: Assignment no, dy, Evan Lenz |
[xsl] The evaluate function, Mark Feblowitz | Date | [xsl] CORRECTION! (was Re: Assignme, Evan Lenz |
Month |