29982 2016-11-06 07:37:36 +0000 [XSLT30] What is this Note, comparing tunnel params with variables in functional languages referring to? 2016-11-17 22:24:49 +0000 1 1 1 Unclassified XPath / XQuery / XSLT XSLT 3.0 Candidate Recommendation PC Windows NT RESOLVED FIXED P2 minor --- 1 abel.braaksma mike public-qt-comments oldest_to_newest 128075 0 abel.braaksma 2016-11-06 07:37:36 +0000 We write, under the definition of Tunnel Parameters (section 10.1.3): "Tunnel parameters are conceptually similar to dynamically scoped variables in some functional programming languages." I am not sure what this refers to. I use functional languages, though, while not claiming to be intimately familiar to all of them, I have not encountered this (unless I am confused by the terminology). However, what *is* very common in all functional languages (except XPath) is currying: let f a b = a + b // function takes two arguments and adds them let g a = f a 12 // create "tunnel" param for a, and fix b to 12 let h = f 42 // other way of creating "tunnel" param, and fix a to 42 Both functions g an f have an argument fixed, one for 12 and one for 42. The parameter a in g a is now tunneled through to f, and in h, which is seemingly without parameter, this is implicitly done. I think that tunneled parameters in XSLT are closest to currying, even though they are distinct techniques. Perhaps the Note in this section is supposed to mean currying with "dynamically scoped variables", but I am not sure. Perhaps the safest thing is to drop it, I find it confusing..., or to be more precise about what we refer to. 128081 1 mike 2016-11-06 13:19:20 +0000 I'm not an expert on this area. There's a brief account of dynamic scoping in the Wikipedia article https://en.wikipedia.org/wiki/Scope_(computer_science)#Dynamic_scoping I think it is found in some dialects of Lisp, Scheme, Smalltalk. The note was put there to answer the question "is there any precedent or theoretical basis for the idea of tunnel parameters": it asserts that such a precedent exists, without going into great technical detail to justify this. I would be reluctant to remove the note, since I think it points the interested reader in the right direction, and I would be reluctant to expand it, since (a) I don't have the technical background to be sure of getting it right, and (b) I don't think it's justified. 128136 2 abel.braaksma 2016-11-10 15:53:09 +0000 I find the Wikipedia discussion fuzzy at best, but from what I read it seems indeed that there are some similarities between tunnel parameters and dynamic scoping. However (nitpicking, sorry), it seems to be a concept irrespective of programming paradigm. You mention Smalltalk (OO language) and Wikipedia mentions Perl (multi-paradigm), Powershell (imperative, OO), Lisp (functional). Either way, I see your point for leaving it in, let's leave it in. 128146 3 mike 2016-11-11 09:46:03 +0000 The editor was asked to attempt to provide a little more context and rationale for the Note. I have redrafted it as follows: <note> <p>Tunnel parameters are conceptually similar to the dynamically scoped variables found in some functional programming languages (for example, early versions of LISP), where evaluating a variable reference involves searching down the dynamic call stack for a matching variable name. There are two main use cases for the feature:</p> <olist> <item> <p>They provide a way to supply context information that might be needed by many templates (for example, the fact that the output is to be localized for a particular language), but which cannot be placed in a global variable because it might vary from one phase of processing to another. Passing such information using conventional parameters is error-prone, because a single <elcode>xsl:apply-templates</elcode> or <elcode>xsl:call-template</elcode> instruction that neglects to pass the information on will lead to failures that are difficult to diagnose.</p> </item> <item> <p>They are particularly useful when writing a customization layer for an existing stylesheet. For example, if you want to override a template rule that displays chemical formulae, you might want the new rule to be parameterized so you can apply the house-style of a particular scientific journal. Tunnel parameters allow you to pass this information to the overriding template rule without requiring modifications to all the intermediate template rules. Again, a global variable could be used, but only if the same house-style is to be used for all chemical formulae processed during a single transformation.</p> </item> </olist> </note> This text has been applied to the spec. Leaving the bug open for WG review. 128211 4 mike 2016-11-17 22:24:49 +0000 The WG reviewed and accepted this text (which is already in the editor's draft).