This is the mail archive of the xsl-list@mulberrytech.com mailing list .


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Re: Re: Assignment no, dynamic scoping si (was: Re: RE: Wishes for XSL revisions ...


Dimitre Novatchev wrote:

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

 
<snip>


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

So, what was the problem?


> 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@regenstrief.org
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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]