[XSL-LIST Mailing List Archive Home] [By Thread] [By Date]

Re: [xsl] current-dateTime()


Subject: Re: [xsl] current-dateTime()
From: "Dimitre Novatchev" <dnovatchev@xxxxxxxxx>
Date: Sat, 19 Apr 2008 09:11:29 -0700

On Sat, Apr 19, 2008 at 12:37 AM, Michael Kay <mike@xxxxxxxxxxxx> wrote:
> > Using this simple principle of dependency (causual) ordering,
> > one can write code that is guaranteed to be evaluated in a
> > certain sequential manner.
>
> While it's true that causes always precede their effects, I think it's very
> hard to take advantage of this fact in a way that is totally resilient to
> processor optimizations. For example if $x depends on $y then it's true that
> you can't finish evaluating $x until you have finished evaluating $y; but
> there is no guarantee that $y will only be evaluated once; the process might
> decide that to save memory, it should evaluate $y every time it is
> referenced; and there is no guarantee that the processor won't start
> evaluating $x before it has finished evaluating $y.

I am accustomed using y(x) and not the oposite x(y).

Again I think the facts are not so complicated.

The *start* of evaluating y (as in the above y(x) ) is by definition
preceding the start of evaluating x, or in other way we say that "the
evaluation of x is triggered by the evaluation of y".

As for the possibility of different references to x being evaluated
more than once, well, this will happen if we have different references
to x, not if there is only a single reference to x.


>
> Even with extension functions written in Java, processors have all sorts of
> tricks they could play if they wanted, such as analyzing the bytecode of the
> extension function to see what use it makes of its arguments, or rewriting
> the bytecode to do lazy evaluation of the arguments. In a processor that did
> JIT compilation of XSLT to Java bytecode, I think such effects might well
> happen.

We were talking about this in order to describe how to disable
memoization. Actually, even the memoization of a regular
<xsl:function> can be prevented if it generates part of (some items
of) its result that are not used by the client of the function and one
of the arguments passed by the client is used to generate that part of
the result. The client will pass always a unique value for this
argument, so even the most intelligent XSLT processor sees that the
set of argument values are different on every reference and are used
for producing the result.



-- 
Cheers,
Dimitre Novatchev
---------------------------------------
Truly great madness cannot be achieved without significant intelligence.
---------------------------------------
To invent, you need a good imagination and a pile of junk
-------------------------------------
Never fight an inanimate object
-------------------------------------
You've achieved success in your field when you don't know whether what
you're doing is work or play


>
> Michael Kay
> http://www.saxonica.com/


Current Thread
Keywords