[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Re: Re: Assignment no, dynamic scoping si (was: Re
Dimitre Novatchev wrote:
<snip>
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.) 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.
regards, -Gunther
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|