On Wed, May 13, 2009 at 1:54 PM, Boyko Bantchev <[email protected]> wrote: >> But since operations on arrays are >> so foreign to other languages, people sort of jammed a >> lot of "related-seeming" features into fold because the >> languages which would be implementing fold could not >> provide them. > > That is possible in principle, but I am not sure what specific > features you mean. Could you give an example?
>From my J influenced point of view, order of operation and initial value are both examples of features. > The real source of diversity seems to be that, in deciding what > a fold is, at least the following issues are involved: These are, in essence, the diversities of various languages. These can be big issues in languages which make them big issues, but in a larger context they are mostly non- issues. I will attempt to outline what I mean here: > • assymetry of lists (efficiency issues arising thereof); > • lazyness; Quoting Donald Knuth We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil http://pplab.snu.ac.kr/courses/adv_pl05/papers/p261-knuth.pdf > • infiniteness of lists; All implementations of infinities are, of necessity, trivial. (They can be useful but only in limited scopes.) > • datatype-related issues (arrays/lists and functions on them > may have types); In my experience, data types are an artifact of the implementation. You can push them out in front of the user of the language, but most of the time this just creates busy work. (Albeit, busy work with some outspoken and loyal fans.) > • issues concerning initial values vs. neutral elements of > the operation being applied. I have wrestled with these issues, many times -- in essence, the non-trivial cases arise when you are using "insert" in contexts where the left domain and right domain are disjoint. In other words, where you are folding values which can not be mixed. Conceptually speaking, this operation is no longer "insert" but is something else entirely different. And, asking that the simple operation (insert) also support the complex case (disjoint fold) is, in my opinion, wrong. This does not mean that the complex case should not be supported -- it should be -- but not by re-specifying the simple case so it is no longer simple. >> J, on the other hand, can reverse the direction of processing >> (in two senses of the word, yielding four possibilities >> involving reversal or not). >> .......................... >> ;~/@|.2 3 5 >> .......................... > > I don't see this as a feature unique to J. Of course not. But since these features are features of J, they can be combined with insert to support the general cases of "fold". > In fact, there are (as mentioned > above) other reasons why many languages have both foldl and foldr. Do you see my point, where for example you could use foldr and reverse to achieve foldl? (And, yes, there can be implementation specific optimization issues, if the implementation is not able to deal with the combination of reverse and foldr efficiently.) > As for flipping the two arguments of a function, this too is > trivial in any functional language. Exactly. So is there any point in objecting, if a fold implementation does not include additional explicit support for flipping arguments of a function? >> Also, for any well behaved function, the initial value >> can be supplied in the list itself. > > Yes, but that often leads to certain inconveniences, e.g. having > to unbox/box the current result within every application of the > inserted function (consider inserting over a numeric list with > an initial value an array). I do not think this case can properly be called "insert". -- Raul ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
