Lambda the Ultimate

Here is another reference, actually about the opposite topic, in the context of relations. Quite interesting:

O. de Moor and J. Gibbons. Pointwise relational programming. (invited paper) T. Rus (editor), Procs. of AMAST 2000, Springer Lecture Notes in Computer Science, Volume 1816, pages 371--390. (available here)

   mean =: +/ % #
   mean 8 6 12
8.66667

  def totient = /+ . @((== . [1, `1] -> `1 ; `0) .
   (while (> . [2, `0]) (< -> reverse ; id) . [2, -]))
   . distl . [id, iota]

to totient   [id, iota] distl  each coprime?  count
to coprime?  [gcd, #1] ==
to count     each (if id then #1 else #0)  insert +


to gcd    // This and `count' ought to be library functions, really.
  while [2, #0] > do (
    [2, -] if < then reverse else id
)

So the real problem with that code is insufficient factoring, plus maybe excessively squiggly notation. OTOH I ended up adding local variables to the language eventually, because without them you do sometimes need to mentally follow values through a chain of manipulations, like stack gymnastics in Forth, and variables are a good way to automate that.

types really help here. i've not used J or whatever the example above is written in, but going from lisp to haskell one of the big things i noticed was that the types helped me follow what was happening, letting me manage higher order functions with less confusion (no particular criticism of lisp implied - i suspect once you're expert at this it's less of an issue, for example).

In general I figure that I will not be a true functional programmer until I am completely comfortable reading and writing point-free code without mentally inserting extra parameters into the code such as the 'a list in the above example.

It is interesting to note the different approaches taken in FP (i.e., Haskell) and in J, in order to achieve "point free style." In Haskell for example, automatic currying is quite essential for this sort of programming style, where as in J the difference between unary and binary functions is quite fundamental.

Perhaps more itneresting is the work on phrasal forms in J. For example the meaning of a "fork" like (+/ % #) x is (+/ x) % (# x), which means sum elements of x and divide by the number of elements in x (give by the # operator). A lot of thought was given to assigning useful meaning to trains of operators (hooks, forks etc.)

Final thought: As J is an array programming language, there are interesting rule regarding rank ("dimensionality"), these apply to trains of operators in ways that vcan cause subtle bugs for those not in the know.

well i immediately thought: "ouch! so what other stupid assumptions have i made about the way languages work just because i read from left to right and write code in lines?"

function f(x,y) { ... }
var g = f.curry(1);

Given this, we leveraged this limitation to support named currying and most every other type of argument binding we could think of.

Moreover, we have an "extened" version of currying in the form of the using() method:

function h(x,y,z) { ... }
var g = f.using(h);

g now becomes a function with three arguments: x, y, z Invoking g as:

g(1, 2, 3);

translates to:

f(h(1, 2, 3), 2);

this is because the y argument is used both by g and h (x is also used by both, but for f it is bound to the value return by h).

using() also provides a mechanism for argument renaming.

Note: I've slightly modified this post to make it more correct and readable