Subject: Re: [xsl] [XSL] Accessing part of the result tree illustrated with "The Sudoku solver" example. From: "Andrew Welch" <andrew.j.welch@xxxxxxxxx> Date: Wed, 5 Sep 2007 13:25:22 +0100 |
On 9/5/07, David Carlisle <davidc@xxxxxxxxx> wrote: > 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. In this case the for-each iterates over items in a sequence (xs:integers), which makes me wonder if the same rule applies? Is it conceivable for a processor to parallelise the processing of a sequence of atomic values and then reassemble the results in sequence order, or does that only apply to nodes and document order? -- Andrew Welch http://andrewjwelch.com Kernow: http://kernowforsaxon.sf.net/
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] [XSL] Accessing part of t, David Carlisle | Thread | Re: [xsl] [XSL] Accessing part of t, David Carlisle |
Re: [xsl] [XSL] Accessing part of t, David Carlisle | Date | Re: [xsl] [XSL] Accessing part of t, David Carlisle |
Month |