
On Tue, 20090113 at 19:23 0500, Anton van Straaten wrote:
> Derek Elkins wrote:
> > No, it means exactly what you said it means. People abuse it to mean
> > the second sense. Those people are wrong and there is already a term
> > for that second sense, namely "partial application." I really wish
> > people would stop conflating these terms*, all it does is create
> > confusion.
>
> +1
>
> > * A related annoyance is people who talk about languages "supporting
> > currying and/or partial application." Unless one means that the
> > language supports higher order functions at all by that, it doesn't make
> > any sense. Haskell has no "support" for currying or partial
> > application. The fact that most functions are in curried form in
> > Haskell is merely a convention (with, admittedly strong social
> > ramifications.) The only way one could say Haskell "supports" currying
> > is that it has a lightweight notation for nested lambdas.
>
> Compared to most other languages, that lightweight notation makes enough
> of a difference that it's reasonable to say that Haskell "supports
> currying and partial application".
>
> E.g., in Haskell:
>
> f x y z = ...
>
> Haskell without the above notation:
>
> f x = \y > \z > ...
This would be adequately lightweight for me, especially in a language
that was impure.
>
> Javascript, to underscore the point:
>
> function f(x) { return function (y) { return function (z) { ... } } }
This is what my javascript looks like. I guess I could implement some
curry functions and write:
curry3(function(x,y,z) { ... })
>
> "Standard" Scheme:
>
> (define (f x) (lambda (y) (lambda (z) ...)))
>
> Scheme with a common macro to "support currying":
>
> (define (((f x) y) z) ...)
>
> That's just the function definition side. On the application side,
> Haskell has a lightweight notation for application in general, i.e. you
> write "f a b c" instead of e.g. "f(a)(b)(c)" in Clike syntaxes or
> "(((f a) b) c)" in Lisplike syntaxes.
>
> Together, these two sugary treats make it quite a bit more convenient
> and practical to use currying and partial application in Haskell (and
> ML, etc.), and this translates to *much* more use in practice.
>
> Anton
I consider the notation "f(a)(b)(c)", both lightweight and ideal syntax
for Cstyle languages. You really, really don't want it to look too
much like normal application in those languages as the "f(a)" part in
the above term can have significant sideeffects, and otherwise it's
almost as minimal as Haskell* which is the most minimal possible.
I will agree that many languages have an extremely verbose syntax for
lambda abstraction. A lightweight syntax for lambdas is very handy. A
good example of this is Smalltalk's blocks which makes using HOFs for
all control structures reasonable. (Smalltalk then messes things up as
far as currying is concerned by having a verbose application syntax.)
Can't account for poor tastes on the part of language designers, though
some are getting hint including Javascript's designers. Examples:
C#2.0:
delegate(int x) { return delegate (int y) { return x + y; }; }
C#3.0:
x => y => x+y  A lighter weight syntax for lambda than even Haskell!
JS1.7:
function(x) { return function(y) { return x + y } }
JS1.8:
function(x) function(y) x+y
* In many cases, equally minimal: f(x+1)(2*x)(x+y) Javascript or
Haskell?
_______________________________________________
HaskellCafe mailing list
HaskellCafe@xxxxxxxxxxx
http://www.haskell.org/mailman/listinfo/haskellcafe

