Lambda the Ultimate

inactiveTopic Currying
started 10/14/2002; 4:01:32 PM - last post 10/17/2002; 2:05:54 PM
Ehud Lamm - Currying  blueArrow
10/14/2002; 4:01:32 PM (reads: 771, responses: 16)
People with superficial knowledge of Scheme or Lisp tend to dismiss their syntax or lack of syntax, and try to invent syntactic sugar that hides the parenthesis. More astute observers realize just how important this language feature is, for example its significance for macros and other forms of language extension.

The more I play with Haskell the more it seems to me that currying is also a very crucial feature that is often seen as a mere curiosity.

Currying really helps with stating theorems and writing high order code, and allows you to write code similar to J's tacit definitions.

Am I right in feeling that currying is so important?

Are there any references dealing with the significance of currying as part of the Haskell language design?

Frank Atanassow - Re: Currying  blueArrow
10/16/2002; 9:52:14 AM (reads: 747, responses: 0)
I'm not sure what you're referring to. "Currying" is a semantic feature; Scheme has currying too, as do all higher-order functional languages.

Do you mean the syntax where you "omit" an argument? For example,

map (map f) xs
or maybe the "sectioning" syntax for infix operators
foldr (+) 0 xs
?

Frank Atanassow - Re: Currying  blueArrow
10/16/2002; 9:59:15 AM (reads: 735, responses: 1)
BTW, in Scheme curry is defined:
(define (curry f x) (lambda (y) (f x y)))
; example
((curry + 1) 2)

Ehud Lamm - Re: Currying  blueArrow
10/16/2002; 10:01:33 AM (reads: 744, responses: 0)
I sensed the problem, but hoped I will be understood...

I am not talking about the semantics, which just like you say, comes free with first class functions.

I was thinking about the syntactical approach, where functions of more than one argument are treated as functions returning functions. From this follows both the properties you mention.

Ehud Lamm - Re: Currying  blueArrow
10/16/2002; 10:06:51 AM (reads: 760, responses: 0)
Maybe some context is in order. I've been palying with equational reasoning, transformations, fusion theorems etc. It was so much fun expressing these in Haskell, beacause you don't need to mention the arguments that don't matter: map f o map g = map (f o g) - no need to mention the list argument.

In fact, when you start thinking about functions explicitly returning functions, Scheme syntax wins. For the theorems, the Haskell approach is nicer.

Frank Atanassow - Re: Currying  blueArrow
10/16/2002; 10:34:49 AM (reads: 729, responses: 0)
I doubt there has been any work on Haskell's currying syntax, though I have a faint memory that Paul Hudak (and others) once wrote a rationale for Haskell, so maybe there is a note on it in there. (I don't know the reference offhand.)

Haskell's syntax for currying, I would guess, was adopted from Curry and Schoenfinkel's syntax for combinatory logic, in which there are no variables as such.

I think, incidentally, that there is nothing preventing a language with Scheme-like "full parenthesization" from having a Haskellish currying syntax. For example, you could define (f 1) to mean (lambda (x) (f 1 x)). But that would conflict with the ability to use that syntax to abbreviate (f (list x)), which is sort of what Scheme/LISP do, if you see what I mean, and I guess McCarthy thought that being able to pass lists easily was more important than being able to curry easily.

Frank Atanassow - Re: Currying  blueArrow
10/16/2002; 10:37:23 AM (reads: 734, responses: 1)
I guess that's not so clear.

What I mean is, Schemers want to be able to write, for example

(+)
(+ 1)
(+ 1 2)
(+ 1 2 3)
etc. all to denote n-ary addition. That conflicts with the desire to have "argument omission" denote currying.

Ehud Lamm - Re: Currying  blueArrow
10/16/2002; 11:05:31 AM (reads: 765, responses: 0)
Of course.

Oleg - Re: Currying  blueArrow
10/16/2002; 3:33:02 PM (reads: 723, responses: 1)
I believe you'll find the discussion of "SRFI 26: Notation for Specializing Parameters without Currying" relevant:

http://srfi.schemers.org/srfi-26/

Frank Atanassow - Re: Currying  blueArrow
10/17/2002; 5:50:20 AM (reads: 714, responses: 1)
In retrospect, I dunno why I mentioned combinatory logic... Church's lambda-calculus also has the same currying syntax.

Ehud Lamm - Re: Currying  blueArrow
10/17/2002; 6:05:19 AM (reads: 728, responses: 0)
Well, you like Hankin's book, and he likes to mix the two systems...

Ehud Lamm - Re: Currying  blueArrow
10/17/2002; 6:09:25 AM (reads: 746, responses: 0)
I was thrilled: an SRFI discussion! But on closer look this specific discussion doesn't seem to be all that enlightening. Or am I missing something?

Noel Welsh - Re: Currying  blueArrow
10/17/2002; 6:42:35 AM (reads: 714, responses: 2)
The best designed functional libraries allow you to glue together lots of little pieces to make the whole you want. Currying allows you to glue together the glue from lots of little pieces. That, to my mind, is the essence of what's good about currying.

Does that make sense?

Michael Vanier - Re: Currying  blueArrow
10/17/2002; 2:05:14 PM (reads: 697, responses: 0)
I understand Ehud's enthusiasm. I felt it too, the first time I used ocaml. I call the feature you're referring to "auto-currying". It's neat because instead of doing this:

(lambda (x) (+ x 1))

you just do (in pseudo-scheme)

(+ 1)

This adds up after a while. OTOH the limitation is that you have to curry the arguments in order. If you want to reverse or change the order you're out of luck. Paul Graham proposed a syntax whereby

[f _ 1]

is equivalent to

(lambda (x) (f x 1))

Of course, if you have multiple arguments, it's not much better than a straight lambda. If you want to keep the purity of the currying approach, you can just use combinators, but that's a whole other can of worms ;-)

Ehud Lamm - Re: Currying  blueArrow
10/18/2002; 7:20:55 AM (reads: 716, responses: 0)
That's part of it, to be sure.

Of course, you can compose functions without currying. But curried (is this a word?) syntax makes the resulting expressions much shorter and more readable.