Re: [xsl] The real harm is in functions with side effects (Was: Re: Using Extension Functions - Its Efficiency)

Subject: Re: [xsl] The real harm is in functions with side effects (Was: Re: Using Extension Functions - Its Efficiency)
From: David Tolpin <dvd@xxxxxxxxxxxxxx>
Date: Mon, 19 Jan 2004 15:52:44 +0400 (AMT)
> What do you mean by 
> first-order functions? Do you see it as a failing of XSLT or something 
> that it should not be concerned about?

First-order functions are roughly functions that can be assigned
to variables and invoked from variables.  Is XSLT 2.0 going to have
something like that?

No, I do not think it is a failing of XSLT; they are just what is
needed to use 'monadic' techniques. XSLT is a very good tool; what
it lacks (or what can in fact be its benefit) is that it is not a
general-purpose language already but not an abstract declarative
notation yet; it requires  a technique different from suitable for
both of the above.

Earlier, I was asking about computational complexity of certain
XSLT constructs; the answer I got is that there is no computational
complexity because there are no computationl semantics in XSLT. In
fact, there is, and many problems with expressiveness and performance
of XSLT stylesheets are caused by it (the lack of realising that
XSLT does in fact compute).

The need for functions, extension functions and side-effects in
XSLT depends on not whether it is 'pure' or 'dirty', but on the
extent a user can rely on its declarative power.

For example, if one can just write //foo[@name=$bar/@name] to
retrieve all foo elements with a given name, then XSLT can go without
keys. If however, it leads to an unaceptably slow computation, then
(xsl:key  'foo' foo @name) has to be used, and XSLT needs keys
because it requires to specify how to compute.

XSLT needs a part of specification, or an accompanying document to the
specification, that will define maximum computational complexity for XSLT
constructs. An implementation of XSLT should be required to follow these
constraints. 

If/when done, it will allow to remove many of the extensions and enhancements
to XSLT 1.0 and replace some other features of XSLT 1.0 with more convenient
and consistent ones. It is not difficult to actually specify computational
complexity and to follow it.

But without it, bugs in XSLT implementations and XSLT stylesheets are easy to
happen and hard to trace.

David Tolpin
http://davidashen.net/

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


Current Thread