Re: [Caml-list] Style question: excessive currying confusion?

[Gerd Stolpmann <info@gerd-stolpmann.de>]

On Thu, 23 Aug 2001, Brady Montz wrote:
>[ I posted this to comp.lang.ml a few weeks ago, before I found this
>  list ]
>
>Howdy ya'll. I'm a long time C and lisp programmer who's taken on
>learning CAML for real. I played with ML a bit a few years ago in grad
>school.
>
>So I'm working through lots of CAML code now, and I find code which
>"excessively" uses currying to be a bit hard to read. I'm curious if
>this gets better with practice, and if anyone has some good style
>rules about this.
>
>So, here's an extremely simple example:
>
>let fun1 x y z =
>  [ x; y; z];;
>
>let fun2 x = 
>  fun1 (x + 1);;
>
>(* alternative implementation of fun2 *)
>let fun3 x y z = 
>  fun1 (x + 1) y z;;
>
>Suppose I'm reading through someone else's program, and I come across
>the definition for fun2, and I want to know what it does. I can't even
>know how many parameters fun2 takes until I refer to the definition of
>fun1. The confusion is worst when I don't even know I'm confused about
>the number of args fun2 can take.

I agree: If there is only one function to call, partial application often has
more disadvantages than advantages. This is different if many functions are
called systematically in the same way. For example:

let f1_general x y z = ...
let f2_general x y z = ...
...

let f1_special = f1_general special_value
let f2_special = f2_general special_value
...

The point is that the reader of such code needs some time to understand how
partial application is used, and this extra time is only worth if there is some
advantage outweighing the extra effort. In this example, the advantage is that
fX_special are systematically derived from fX_general, and once you understand
partial application in this case you understand the system, and vice versa.

>Now, in most cases I've hit the confusion would have been much
>lessened with proper function naming and commenting, but not always. 
>
>Now, on the other hand, there are times when currying is obviously
>great. For example, if it is really important to me that fun2 always
>have a similar signature to fun1, then this seems fine to me. Also,
>there is benefit to keeping the code succinct.

Another example:

let preprocess_case1 a b x y z = ...
let preprocess_case2 c x y z = ...
let preprocess_case1 d e f x y z = ...

let f ... =
   ...
   let g =
     match v with
       Case1 a b   -> preprocess_case1 a b
     | Case2 c     -> preprocess_case2 c
     | Case3 d e f -> preprocess_case3 d e f
   in
   g x y z
   ...

Three different cases are generalized into a common function g, and called with
the remaining arguments x y z. Again, partial application is only useful
because there are several instances for it. And again, there is some system
(here: generalization), and it expresses a concept the author had in mind when
writing the code.

As a rule of thumb: If there is only a single call with partial application, it
is almost always more confusing than helping. And if there are good names for
partially applied functions, take this is indicator that currying is right.

Gerd
>-- 
> Brady Montz
> bradym@balestra.org
>-------------------
>Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
>To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr
-- 
----------------------------------------------------------------------------
Gerd Stolpmann      Telefon: +49 6151 997705 (privat)
Viktoriastr. 45             
64293 Darmstadt     EMail:   gerd@gerd-stolpmann.de
Germany                     
----------------------------------------------------------------------------
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr