Re: [xsl] [saxon] Questions about the `saxon:threads` extension attribute

["Michael Kay mike@xxxxxxxxxxxx" <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx>]

> On 2 Jan 2020, at 22:28, Dimitre Novatchev dnovatchev@xxxxxxxxx
<xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx> wrote:
>
> > (1) fn:unordered doesn't relate very well to xsl:for-each because
functions can't be applied directly to instructions; it would make more sense,
> > > I think, to add a saxon:unordered attribute to xsl:for-each.  I don't
think it's a particularly easy change to make, given the existing code,
> > > though I'm sure it could be done. One question is whether the result
corresponds to some permutation of the input sequence,
> > > or to some permutation of the output sequence (that is, are the multiple
result items corresponding to one input item
> > > deliverered in the "correct" order? Getting that right depends on
understanding the use cases, and I'm not sure I do...
> >
> > In this case we need a permutation of the input sequence.
>
> More precisely, we need fn:unordered($vmultithreadingResults) to produce the
items in $vmultithreadingResults in the order that they are being produced

The problem there is that before evaluating the for-each in unordered mode, we
need to know that all references to the variable don't care about ordering.
That kind of analysis isn't impossible, but it's also rather fragile; you only
need to add an xsl:message that prints the contents of the variable, and you
change the way it's evaluated, with no visibility as to why adding diagnostics
has changed the result. A saxon:unordered attribute on the xsl:for-each itself
would be much more robust.

Michael Kay
Saxonica