Re: [xsl] Need help with XSLT tokenize

["John Lumley john.lumley@xxxxxxxxxxxxxx" <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx>]

Like Eliot, I have been using xsl:iterate for good while, in some cases
replacing a recursive template to give a little more coherence. In a few cases
I still need to use recursive templates as the problem canbt be coerced into
a tail-recursive situation (I.e. next-iteration was needed at a non-tail
position).

What xsl:iterate supports is the notion that in the bnextb iteration only
one or a few of the context variables changes state.... this means that,
unlike using recursive templates, you donbt have to list all the rest of the
unchanged parameters/arguments/variables In the recursive call. This generally
means fewer mistakes, the compiler handling the continuity of context
scope....

And iterations can be scoped inside iterations, inheriting parental state...

John Lumley
john@xxxxxxxxxxxxxx

> On 13 Aug 2020, at 17:47, Eliot Kimber ekimber@xxxxxxxxxxxx
<xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx> wrote:
>
> o;?Having written my share of non-trivial recursive templates, I will attest
that xsl:iterate, once I worked how to use it, is much easier for me to both
understand and apply and I would expect most procedural programmers to have a
similar experience.
>
> Which is not to discount Dimitre's experience in any way, just saying that
my experience was very different.
>
> I do agree that trying to understand xsl:iterate from the spec alone is a
little challenging, but a few examples go a long way there.
>
> Cheers,
>
> E.
>
> --
> Eliot Kimber
> http://contrext.com
>
>
> o;?On 8/13/20, 10:41 AM, "Dimitre Novatchev dnovatchev@xxxxxxxxx"
<xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx> wrote:
>
>
>
>>
>
>>
>
>
>
>    What about XSLT 3's xsl:iterate? Isn't that, with its parameters that
>
>>
>
>> can change on each iteration step, close to a procedural, sequential loop?
>>
>
>
>>
>
>    I prefer to think of it as syntactic sugar for a functional fold
operation, or for a tail-recursive function.
>
>>
>
>    It means that processing the Nth item has a functional dependency on
processing the (N-1)th,
>
>>
>
>    but a functional dependency is not quite the same as a defined order of
execution.
>
>    If you read the spec for <xsl:iterate> it is quite likely you will find
it much more overwhelming and confusing than the clean and clear description
of a fold (in Haskell and also in the Functions and Operations spec).
>
>    In my case it cost me more than 2 hours to read the spec of <xsl:iterate>
and at the end I was not sure I properly understood what exactly this XSLT
instruction does and whether or not it was possible to use it in a few edge
cases. I spent another hour to construct one of these edge cases and made sure
this was handled properly in Saxon, however this confirmation came from Saxon,
not from the spec.
>
>    For me, the <xsl:iterate> instruction is a deviation from the spirit of
XSLT and I am not sure whether or not it will serve its stated goal to help
imperative programmers not learn and use recursion.
>
>    It would have been much better to (more or less) formally define the
concept of "tail recursion" and make it clear that a good implementation can
(or should) optimize tail recursion with iteration.
>
>    Dimitre
>
>
>    On Thu, Aug 13, 2020 at 3:55 AM Michael Kay mike@xxxxxxxxxxxx
<xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx> wrote:
>
>
>
>
>    What about XSLT 3's xsl:iterate? Isn't that, with its parameters that
>    can change on each iteration step, close to a procedural, sequential
loop?
>
>
>
>
>
>
>    I prefer to think of it as syntactic sugar for a functional fold
operation, or for a tail-recursive function. It means that processing the Nth
item has a functional dependency on processing the (N-1)th, but a functional
dependency is not quite the same as a defined order of execution.
>
>    For example, if the code did
>
>    <xsl:when test="self::H1">
>      <xsl:next-iteration>
>        <xsl:with-param name="pos" select="1"/>
>      </xsl:next-iteration>
>    </xsl:when>
>
>    then a smart optimizer could work out that processing the item following
an H1 doesn't depend on anything that went before, and could therefore be done
in parallel with processing of previous items. Unlike a loop, the functional
depenendency is explicit and it's therefore still possible in principle to
rearrange the order of execution.
>
>    Michael Kay
>    Saxonica
>
>
>    XSL-List info and archive
<http://www.mulberrytech.com/xsl/xsl-list>EasyUnsubscribe
<http://lists.mulberrytech.com/unsub/xsl-list/782854>
>    (by email <>)
>
>
>
>
>
>
>
>
>
>    XSL-List info and archive
<http://www.mulberrytech.com/xsl/xsl-list>EasyUnsubscribe
<http://lists.mulberrytech.com/unsub/xsl-list/1278982>
>    (by email <>)