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

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

[Brady Montz]

John Prevost <jprevost@panasas.com> writes:

> On 23 Aug 2001, Brady Montz wrote:
> 
> > 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.
> 
> Note that thinking in terms of "number of arguments that fun2 can
> take" may not be what you want to do, in any case.  In a functional
> language, functions are often good "data", and make reasonable return
> values.  Typically, a good API will hide the fact that there's a function
> underneath, though.

I'm willing to believe this.

> Also note that the type of your fun2 (which may or may not be easy for you
> to determine) will quickly reveal that it takes more arguments.
> 
> In general, I tend to write out all the parameters when I don't think
> it'll be clear, when the functional result isn't being treated as a
> "data" result, or when the let restriction would make the function result
> monomorphic otherwise.

Perhaps it just comes down to: the more clearly defined and/or documented
a function is, the easier it is to understand and use. 

-- 
 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

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

[Brady Montz]

[ 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.

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.

So, anyhoo, if anyone has helpful advise to this ML newbie, I'd much
appreciate it. 

-- 
 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

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

[Gerd Stolpmann]

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