Lambda the Ultimate

This is 100% correct, in a very precise technical sense. The proposed foo function is the Church encoding of a tuple.

Let's look at the definition of bar (cut down to pairs for simplicity):

   bar = fun k -> k arg1 arg2

will have the type ∀c. (A → B → c) → c (assuming arg1 has type A and arg2 has type B). In a functional language this is provably equivalent to just having a pair containing arg1 and arg2. This is due to parametricity, and arises as one of Wadler's "theorems for free".

So if I wrote a function foo

   foo a b = fun k -> k a b 

I would prefer to call it makePair or something similar. However, I would try not to write such a function unless my language lacked support for tuples -- higher-order code is harder to understand than first-order data.

Which is just the same as saying it's a bad code smell, and you should try to introduce a parameter object if you can.

John, I think you're right! It is essentially a right-curry'd apply--or right-partial'd apply, depending...

Perhaps applywith() might be appropriate.

In any case, I'm really glad to get this feedback. Thanks, everyone.

Currying is something you do to types. Specifically the transformation of a multi argument function into several single argument function applications in the type signature. Note, it does not imply partial application, it is a way of simplifying the implementation of type systems. For example:

f :: a * b -> c => f :: a -> b -> c

Partial application is applying some but not all arguments to a function, so it does not seem right here either. Right partial application would bind the rightmost arguments first

This transformation is:

f1 :: a * b * c * d * e -> r1
f2 :: a * b * c * d * e -> r2

g :: a * b * c * d * e -> ((a * b * c * d * e -> r) -> r)

Which doesn't look like either of those. I don't get what "right currying" would be, but right partial application would just be binding the rightmost argument first, which does not seem to fit the above signature for 'g'.

In any discussion I've read or heard, Currying has nothing to do with types [non-overlapping sets of discussions?]; it's simply a technique for breaking up an n-ary function into a chain of binary functions. It'd be more historically accurate to name the technique after either Frege or Schönfinkel, but then, there's a long academic tradition of naming things after people not responsible for them.

For these Kleinian groups Poicaré obtained new automorphic functions, [...] which he called Kleinian functions. These functions have properties analogous to the Fuchsian ones [...]. Klein had considered Fuchsian functions while Lazarus Fuchs had not. Klein therefore protested to Poicaré. Poicaré responded by naming the next class of automorphic functions that he discovered Kleinian because, as someone wryly observed, they had never been considered by Klein. — Morris Kline, Mathematical Thought From Ancient to Modern Times

Yes, you are right, I was perhaps thinking about the difference between partial application and partial evaluation, and that currying does not imply partial evaluation. It does of course imply partial application.

I can't quite make right currying work though, it would seem to get stuck with a single argument, I can pass the first argument to a function 'f' and I can pass 'f' to 'g' but I can't get any extra arguments in there. I suppose its needs a pair, and the operator would be make pair, then you can pass f(makePair(makePair(a, b), c))

In this case the function 'foo' constructs a new function 'bar' that applies a tuple to its argument. So 'bar' would be "applyTuple" and that would make 'foo' something like "makeTupleApplicator" :-)

Perhaps right-apply can be overthought. A notion I've been developing for some time is that the core flaw of most programming languages is trying to mediate a dialog between human programmer and computer, which is guaranteed to stifle the human because dialog between humans takes place at a sapient level whereas, to communicate with a computer, the human has to sink to the computer's nonsapient level. (In contrast, mathematics is traditionally a dialog between human mathematicians.) Currying is first-and-foremost a technique used by humans; the moment you try to bring it down to the computer's level it starts to get difficult. In this particular case, apply is a function of exactly two arguments, and it's straightforward for a human to break it down right-to-left:

($lambda (args) ($lambda (func) (apply func args)))

or, to avoid the explicit use of apply,

($lambda (args) ($lambda (func) (eval (cons func args) (make-environment))))

let's say we want a function right-curry, that takes a single argument and returns a function that, when called, will take one or more elements and tack that single argument onto the end. So we can write (f x y z t) as ((right-curry t) f x y z).

($define! right-curry
   ($lambda (arg)
      ($lambda left
         (eval (append left (list arg))
               (make-environment)))))

We could also rewrite (f) as ((right-curry f)).

[You're quite right, of course, that this requires meta-programming capability, incarnated here by eval]

($define! right-curry
   ($lambda right
      ($lambda left
         (eval (append left right)
               (make-environment)))))

Which allows things like ((right-curry z t) f x y).

I see where you are coming from, but isn't currying a transform so that all functions take a single argument? Look at the types of curried languages functions can only take a single argument. I understand how you are using right currying, but it does not quite seem to fit, because you need a multi argument function at some point.

I would argue there are no right or left curring transforms. There is in fact a single "curring" capable of transforming a program with multi-argument functions into entirely functions that take a single argument. Hypothesis: In the universe of lambda calculus there is one and only one minimal transform capable of taking a program with multiple argument functions and returning a program using only single argument functions. By minimal I mean without adding non-operations like the identity function.

I accept that people can be fuzzy in their thinking, but from my experience subjecting that thinking to the rigour of a programming language has in every case exposed the weakness of such thinking and resulted in either an improvement in clarity or the rejection of the idea.

But, I'm not talking about fuzzy thinking; I'm talking about sapient thinking. As a civilization we've developed one conceptual framework for placing ourselves in a hierarchy where a Deity is above us and mechanisms are below us, and another conceptual framework in which broadside techniques such as evolution and "big data" are essentially above us; the trouble, I've recently concluded, is trying to order these things. We're neither above nor below the broadside techniques; there are things sapience can do that broadside techniques can't, and vice versa. But we've got no conceptual framework for describing the things that each of these techniques can do that the other can't, only for portraying one as "better" or "smarter" than the other.