[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Esoteric XSLT/FXSL question - foreach versus map
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? >> ---------------------------------------------------
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|