Re: [xsl] Esoteric XSLT/FXSL question - foreach versus map

Subject: Re: [xsl] Esoteric XSLT/FXSL question - foreach versus map
From: "Dimitre Novatchev" <dnovatchev@xxxxxxxxx>
Date: Thu, 29 May 2008 08:26:57 -0700
Continuing from my prev. message.

Justin,

Your statement is actually not that f:map() and <xsl:for-each> are
different in XSLT, but that the type of some functions cannot be
expressed and is flattened in XSLT.

For example, we cannot express that the result of mapping a function
f() that produces a sequence T* is a sequence of sequences: (T*)*

simply, because there isn't anything like sequence of sequences in XPath.

So, please, send this message again under its correct subject.

While your observation *is* correct, this doesn't mean at all that
there is no way to represent a sequence of sequences: everyone on this
list knows how to do it and has done this many times (hint: think of
markers, or mark-up or XML document/fragment).

Whether this is an efficient representation of nested sequences is a
totally different topic.


-- 
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 8:11 AM, Dimitre Novatchev <dnovatchev@xxxxxxxxx> wrote:
>> 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?
>> ---------------------------------------------------

Current Thread