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

> From last week (sorry haven't had time to be back since),
Dimitre,

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

Except, of course, Justin, you were saying?

There is no need, Dimitre, for you to be condescending in reply and there
is no need
(for me) to "send this message again under its correct subject" especially
given
that you agree " your observation *is* correct".

My original post was about the semantics of "for-each" vs "map" and, in
subsequent
discussion, how the concepts of null-ness and nested sequences are emergent
from
these semantics.  I was not seeking a hint or a hack to *emulate* nested
sequences
in FXSL or anything else, rather, just questioning semantics of the
respective idioms.

Given that "A proof through examples" suggests that, in your scientific
method, examples are
valid way of "proving things", me gives the following examples from the
Mozilla Javascript
code base in which "foreach" and "map" are differentiated as separate
functions:

/*
  Array.prototype.forEach
  
  Attribution:

http://developer.mozilla.org/en/docs/Core_JavaScript_1.5_Reference:Objects:A
rray:forEach
*/
if ( !Array.prototype.forEach)
{
  Array.prototype.forEach = function( f /*, thisp*/)
  {
    if ( typeof f !== "function")
      throw new TypeError();

    var thisp = arguments[1];
    var len = this.length;

    for ( var i = 0; i < len; ++i) {
      if ( i in this)
        f.call( thisp, this[i], i, this);
    }
  };
}

/*
  Array.prototype.map
  
  Attribution:

http://developer.mozilla.org/en/docs/Core_JavaScript_1.5_Reference:Objects:A
rray:map
*/
if ( !Array.prototype.map)
{
  Array.prototype.map = function( f /*, thisp*/)
  {
    if ( typeof f !== "function")
      throw new TypeError();

    var thisp = arguments[1];
    var len = this.length;
    var res = new Array( len);

    for ( var i = 0; i < len; ++i) {
      if ( i in this)
        res[i] = f.call( thisp, this[i], i, this);
    }

    return res;
  };
}

I trust this is food for thought and constructive towards future XSLT/XPath
incarnations,

Justin Johansson


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

Original thread message:

XSLT has been shown to be a member of the "Functional Programming (FP)
Family of Languages".

see:
http://fxsl.sourceforge.net/articles/FuncProg/Functional%20Programming.html

> From the above, and other observations, it is fair conjecture that XSLT is
more "functional" as opposed to "imperative".

The FP idiom, sporting lazily and readily optimizable computation, suggests
that functions can be forced to produce a result (i.e. actually calculate
something) only when the result is needed for some ultimate calculation.
This is achieved thru side-effect-free realization of functions.  Given
this, then a side-effect-free aware functional optimizer can execute
"stuff" in any order (so long as the computations have no side-effects).
Somehow, the notion of calculation, in an FP sense, sublimes time and
therefore ordering of output.

Now, the FP alphabet of functions includes as its signature functions,
"map", "fold" (aka "reduce") and so on.

However "so on" rarely includes "foreach" as a signature function of the FP
idiom.  Is this because "foreach" implies some kind of time ordered
calculation, and therefore not optimizable?

Noting that xsl:foreach always produces the same ordered output (in a
result document), does this imply that XSLT breaches the pure FP idiom,
recognizing, of course, that XSLT has never claimed to be an FP language?

Perhaps I've been eating too much monadic fungi, but there seems to be a
something about the essence of "foreach" as opposed to, say, map, in an FP
context that needs explanation.

Whatever the explanation, it still seems difficult to me to say what the
heck of a kind of a language XSLT actually is :-)

Justin Johansson


--~------------------------------------------------------------------
XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--