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

Subject: Re: Assignment no, dynamic scoping si (was: Re: [xsl] RE: Wishes for XSL revisions ...
From: Gunther Schadow <gunther@xxxxxxxxxxxxxxxxxxxxxx>
Date: Tue, 01 Jan 2002 22:23:12 -0500
David Carlisle wrote:

> anyone arguing for the addition of an new scoping mechanism
> needs to argue that the benefits are worth the costs, given
> the features proposed in xslt 2.

So, what are the disadvantages of dynamic scoping?

I can see only two: (1) implementors of XSLT have to implement
it. And (2) there are some concerns with dynamic scoping and
functional arguments.

I think that (1) is probably the only argument against dynamic
scoping that has a chance to stand, because the knowledge about
functional arguments is younger than dynamic scoping. The
FUNARG and CLOSURE constructs of LISP have been the typical
answer to the problem. Time tested for at least 25 years. What
about these?

I want to say that I do respect Dimire a lot for what he
knows and does before I say that I am also pretty frustrated
by his way of arguing this in the last few days. All he does
is shoot me or Terje down with lapidar "you are wrong, I am
right" kind of arguments without even responding to the
meat of what people say.

Terje's use case example for dynamic scoping is *EXACTLY*
what I have in mind and he expressed it so much better. So,
please read it again and tell me what if not dynamic
scoping would meet the need of this use case.

I really would like to hear some more voices about this issue,
for and against dynamic scoping. I am ready to accept not
having it if someone can make an argument why exactly it is
bad. It is certainly not enough to just say that it's bad
repeatedly.

So, the two questions to answer is

(A) where do functional arguments play a role in XSLT at all?
I cannot see any way to pass functions as arguments or return
functions from functions in XSLT. If XSLT doesn't have functional
arguments, those can't be a reason against dynamic scoping in
XSLT.

And (B) why is the Common LISP CLOSURE or the earlier
FUNARG (that keeps the binding of the function's free
variables with the functional arguments) not a sufficient
solution?

Also keep in mind that we are not asking for dynamic scoping
as the default, but as something one can set on particular
variables as an option. The shallow-binding would be the
natural way of implementing those. This is not so hard to do.

regards
-Gunther


Here is Terje Norderhaug's use case again for your convenience:


Being able to simplify the stylesheet by removing repeated parameter
passing is reason enough for me. However, I have also missed variables
with dynamic scope when extending predefined stylesheets.

Dynamic scoped variables may reduce the redundancy between imported
and importing stylesheets, with associated benefits. It makes
imported/importing stylesheets less dependent on each other by
allowing passing of values between templates in a stylesheet without
demands on the templates in the other stylesheet.

Say you have a stylesheet "book.xsl" containing templates to process
the various element types in a book (e.g. book, chapter, paragraph,
...) where each template applies templates recursively, like this:

<xsl:template match="chapter">
  <fo:block>
    <xsl:apply-templates/>
  </fo:block>
</xsl:template>

Consider the case that you need to make a stylesheet that imports a
third party "book.xsl" then overrides its templates for 'book' and
'paragraph' elements with custom processing but with a minimum of
duplication. For some reason, you would like to pass a parameter from
the 'book' template to the 'paragraph' template.

Unfortunately, today this requires that you duplicate and modify the
'chapter' template (and possibly others) from the "book.xsl"
stylesheet to pass along the parameter. You end up with a stylesheet
that contains most or all of the imported stylesheet.

With support for dynamic scope, the 'book' template would be able to
bind variables that are visible for the 'paragraph' template without
requiring modifications of other templates in "book.xsl".



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



XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list


Current Thread