Re: Esoteric XSLT/FXSL question - foreach versus map

> Now, for "for each" and "map" to be 100% tautologous, would, imho, require
> that
> (in the XPath environment) sequences allow "null" or the empty sequence to be
> a valid item within a sequence, or, in other words, sequences may contain
> nested
> sequences, including the empty sequence itself.  As XPath has no notion of
> nested
> sequences, and, from my memory of the spec, null-ness is represented by
> empty-ness
> (i.e. sequences of exactly zero items).
>
> Accordingly, foreach and map are not quite the same thing when the XPath
> data model
> does not allow for nested sequences.  Whether the omission of nested
> sequences from
> the XPath model was a good thing, a pragmatic thing, or a bad thing, I am
> not quite sure.
>


In XSLT context <xsl:for-each> and implementations of map() *are* the
same thing, because their results are indistinguishable (identical).

For example, these two sequences are identical in the XPath 2.0 data model:


1, 2, (), 3

1, 2, 3


Also, there is no way to claim that <xsl:for-each> has really produced
the second sequence...



-- 
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


On Thu, May 29, 2008 at 7:43 AM, Justin Johansson <procode@xxxxxxxxxxx> wrote:
> Thanks folks for explanations.
>
>> Dimitre
>> There is ordering of the *results*, not of the application of the body
>> of <xsl:for-each> to the elements of the sequence.
>
> Yes, I understand.  It was the result ordering that got me thinking about
> I/O monads controlling the sequential output (and boiling down to joins
> on multi-processor threads). Sounds like Colin has a take on managing
> this (parallelism) as well.
>
>> Michael Kay
>> The use of the English words "for each" is a mixed blessing. On the one
>> hand, it makes your typical user less uncomfortable than if it were named
>> xsl:map. On the other hand, it gives people the wrong impression that it is
>> procedural.
>
> Okay, I went away thinking that "for each" and "map" were synonyms
> but upon reflection me thinks that these terms/names are subtlely different.
>
> Refer your example
>
> <xsl:for-each select="S">
>  <instructions/>
> </xsl:for-each>
>
> The concept of "for each" means, at least to me, to do something and to
> produce
> a result (sequence) of zero or more items against corresponding items in
> the input
> sequence to "for each".
>
> "instructions" has a general result signature of item()*.  Conceivably, the
> overall result
> could be the output of zero items for a non-empty argument sequence given
> to "for each".
>
> The concept of "map" however, generally suggests, say, a 1-N mapping
> of input items to result items as produced by the higher-order application of
> "instructions", N generally being a constant >= 1, certainly not variable and
> generally not zero either.
>
> In a "mapping" context, "instructions" has a signature like
> instructions ( arg as item()) as item() and not
> instructions ( arg as item()) as item()? as may be a use case for "for each".
>
> Trustingly this argument is clear enough to demonstrate the different between
> the notions of "for each" and "map".
>
> Now, for "for each" and "map" to be 100% tautologous, would, imho, require
> that
> (in the XPath environment) sequences allow "null" or the empty sequence to be
> a valid item within a sequence, or, in other words, sequences may contain
> nested
> sequences, including the empty sequence itself.  As XPath has no notion of
> nested
> sequences, and, from my memory of the spec, null-ness is represented by
> empty-ness
> (i.e. sequences of exactly zero items).
>
> Accordingly, foreach and map are not quite the same thing when the XPath
> data model
> does not allow for nested sequences.  Whether the omission of nested
> sequences from
> the XPath model was a good thing, a pragmatic thing, or a bad thing, I am
> not quite sure.
>
> Cheers
>
> Justin Johansson
>
> ---------------------------------------------------
> A horse with no name is called Lambda.
> What was the name of the town in the song?
> ---------------------------------------------------