Re: [xsl] [XSL] Accessing part of the result tree illustrated with "The Sudoku solver" example.

Subject: Re: [xsl] [XSL] Accessing part of the result tree illustrated with "The Sudoku solver" example.
From: David Carlisle <davidc@xxxxxxxxx>
Date: Wed, 5 Sep 2007 13:15:31 +0100
> [I wonder if any XSL processor would be optimized enough to

if a recursive function is writen in a tail recursive style then it can
be optimised to not use up stack space and saxon does this pretty well
these days.

> saxon:assignable="yes"

however I assume that  if you use saxon:assignable virtually all
optimizations that a ssyetm might want to do are invalid as the whole
point of side effect free declarative programming is to allow such
rewrites and optimizations without affecting the result.

> So I would expect, as we have a "current context", "current node"... to 
> have a "current-loop-result" being result output by preceding-siblings 
> of the sequence selected by the current for-each or apply-templates (or 
> other loop-like constructs).

Such a construct would only really be useful if you could rely on the
processor evaluating all the items  in a for-each in order, but that is
explictly not the case. One of the benefits of a side effect free
language is that it is naturally parallelisable. It's best to assume
that all the items in a for-each are evaluated in parallel, and the
results assembled at the end and passed on. If you view it this way the
fact that you can't "stop" a for-each based on the processing of one of
the items should seem far more natural. If you need the processing of
one item to depend on the result of processing another, don't use
for-each, use a recursive template that processes the item and then just
conditionally processes the next item if needed.

> *** "Clean" solution *****
> As the for-each prevents you from knowing what happened with the 
> preceding-sibling of the current node in the selected sequence... just 
> don't use for-each and replace it with a recursion on each element of 
> that sequence.

Exactly!  If you have a tail recursive template that appears to be
eating stack space then you should submit it to the xslt system
maintainer to see if it can be improved. It should be the system's job
to rewrite a recursive algorithm as an efficient loop, not the end

Further discussion about excatly what saxon can and can not recognise as
tail recursive:


The Numerical Algorithms Group Ltd is a company registered in England
and Wales with company number 1249803. The registered office is:
Wilkinson House, Jordan Hill Road, Oxford OX2 8DR, United Kingdom.

This e-mail has been scanned for all viruses by Star. The service is
powered by MessageLabs. 

Current Thread