This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 29982 - [XSLT30] What is this Note, comparing tunnel params with variables in functional languages referring to?
Summary: [XSLT30] What is this Note, comparing tunnel params with variables in functio...
Status: RESOLVED FIXED
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: XSLT 3.0 (show other bugs)
Version: Candidate Recommendation
Hardware: PC Windows NT
: P2 minor
Target Milestone: ---
Assignee: Michael Kay
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-11-06 07:37 UTC by Abel Braaksma
Modified: 2016-11-17 22:24 UTC (History)
0 users

See Also:

Attachments

Description Abel Braaksma 2016-11-06 07:37:36 UTC 
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.
Comment 1 Michael Kay 2016-11-06 13:19:20 UTC 
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.
Comment 2 Abel Braaksma 2016-11-10 15:53:09 UTC 
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.
Comment 3 Michael Kay 2016-11-11 09:46:03 UTC 
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.
Comment 4 Michael Kay 2016-11-17 22:24:49 UTC 
The WG reviewed and accepted this text (which is already in the editor's draft).