First, I am still bemused by the lack of citations for Iversion's work. Also, of course, "/" is not "pure notation" -- it also has meaning and significance. You are right that the significance allows for a variety of implementations, but I do not see that as an obstacle. I think you recognize this with your explanation of why you used that phrase.
A significant issue, here, is that the initial focus of Iverson's work was: a) describing the behavior of computer hardware b) presenting this in a digestible form, for other people Meanwhile, what's a function? Even now, J does not have "functions" -- it has Verbs, Adverbs and Conjunctions. Haskell has functions, and as a result it's far more complicated than J. There are of course benefits to the Haskell approach but there are also advantages to the J approach. And it's true that the APL and J family have incorporated ideas and concepts developed by other people -- and they can be convenient. Still, the core of APL and J is primitive recursive, rather than recursive. The reason "goto" is so maligned is that it is so powerful -- too powerful. -- Raul On Tue, Nov 6, 2012 at 8:56 AM, Boyko Bantchev <[email protected]> wrote: > In a previous post, I pointed out several respects in which > Strachey' Lit (equivalent to a right fold in a modern language) is > more general than what was '/' (or 'reduction') in APL at the time. > Given the deep influence that Strachey's work have had on the > development of ideas in both imperative and functional programming, > it is no wonder that Lit, implementing a simple yet versatile > programming paradigm, received due attention and is now a standard > function in many functional languages. Lit is not a precursor of > the modern fold -- it IS that fold. > > As for comparing Lit to Iverson's '/' of that time, it is useful to > explicitly stress the following, in addition to the differences that > I previously summarized. > > Iverson's notion of '/' was purely notational: '/' can be understood > as a general symbol, which, combined with other symbols, was meant to > replace the use of dissimilarly looking n-ary 'summations' such as > ∑, ∏, ∪, and ∩. I say 'purely notational' in order to contrast it > with any programming-related interpretation. > > APL itself was, at the time, a notational system, a pseudo-code, > and not a programming language per se. It is rather telling that, > e.g., 'A Programming Language' (the book) does not define what a > subroutine is, how it can be defined and how it communicates with > its environment (arguments? local/non-local/global variables?). > In fact, the book barely mentions the very notion of subroutine. > Much more attention is devoted to branches (gotos), with surprisingly > low-level details being specified. > > Also, in the then-APL there wasn't even a hint that a subroutine > (a function) could be treated as a value -- values in that APL are > numbers and arrays of them, that's all. Accordingly, there is no > trace of 'functional programming' (let alone function-level!) in > Iverson's ideas from that time. > > A fold (Lit in Strachey's terms), in contrast, is truly a programmer's > tool, invaluable for list processing in functional style. And, > functions (closures) being first-class objects in CPL, they could be > both arguments to, and results from other functions, parts of data > structures etc. Lit itself is just another function, easily > expressible within the language. > > In APL, even when '/' indeed became a program object, it was not > given equal rights with the ordinary functions, and was not treated > as a value at all. The distinction between 'functions' and > 'operators', so characteristic of APL (and its successors) is a > reminder that it took time before the so called operators received > recognition as program objects. > > All this does not, of course, diminish the value of K.Iverson's work. > But due recognition must be given to many other great scientists who > shaped the discipline of computing. With respect to Lit/fold (as well > as many other things), we owe respect to Christopher Strachey. > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
