🚀 go-pugleaf

In article <23795@alice.att.com> ark@alice.att.com (Andrew Koenig) writes:

   In article <TMB.92Oct4181821@arolla.idiap.ch> tmb@idiap.ch writes:

   > Why _do_ people continue to use curried syntax when they just want a
   > function with several arguments?

   Perhaps because it makes partial application easier to write.

   For example, if I want a vector whose elements are twice the corresponding
   elements of x, I can write

	   map (fn x => x * 2) x

   or, if I have a curried multiply function, I can write

	   map (mult 2) x

True. There are some functions for which partial application is not
infrequent. Those functions, I curry myself. However, I find those
functions are quite rare.

   I suppose I might ask the complementary question: why should compilers
   generate slower code for curried functions if I don't happen to make
   use of that property?

If you have a definition like

	fun f x y z u = ...

then the compiler doesn't know which way you intend to call it.  If it
wants to generate efficient entry points for it, it has to generate
four different versions of the function, or it has to make a guess,
generate one efficient entry point, and do the appropriate (slow)
transformation in the caller.

If you have a definition like

	fun f(x,y,z,u) = ...

then the compiler knows that you will call it either with four
arguments or with a tuple. That means that you have at most two
entrypoints to the function (probably, usually, calls like "f arg"
will do the destructuring in the caller, giving you only a single
entrypoint).

I think the efficiency issue is not as significant (although in NJ/SML
it's a factor of 2-3 in the benchmarks that I posted); mainly what
bothers me is that curried type signatures are much less informative
to me as a reader, and that missing arguments are not diagnosed by
the compiler.

					Thomas.