From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id VAA08210; Thu, 23 Aug 2001 21:39:19 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id VAA08516 for ; Thu, 23 Aug 2001 21:39:18 +0200 (MET DST) Received: from moutvdom01.kundenserver.de (moutvdom01.kundenserver.de [195.20.224.200]) by nez-perce.inria.fr (8.11.1/8.10.0) with ESMTP id f7NJdHX04467 for ; Thu, 23 Aug 2001 21:39:17 +0200 (MET DST) Received: from [195.20.224.220] (helo=mrvdom04.kundenserver.de) by moutvdom01.kundenserver.de with esmtp (Exim 2.12 #2) id 15a0Jx-0002iZ-00; Thu, 23 Aug 2001 21:39:17 +0200 Received: from drms-3e36538d.pool.mediaways.net ([62.54.83.141] helo=ice.gerd-stolpmann.de) by mrvdom04.kundenserver.de with esmtp (Exim 2.12 #2) id 15a0Jw-0005on-00; Thu, 23 Aug 2001 21:39:16 +0200 Received: from localhost (localhost [[UNIX: localhost]]) by ice.gerd-stolpmann.de (8.9.3/8.9.3) id VAA12911; Thu, 23 Aug 2001 21:39:09 +0200 From: Gerd Stolpmann Reply-To: info@gerd-stolpmann.de Organization: privat To: Brady Montz , caml-list@inria.fr Subject: Re: [Caml-list] Style question: excessive currying confusion? Date: Thu, 23 Aug 2001 21:13:51 +0200 X-Mailer: KMail [version 1.0.28] Content-Type: text/plain References: In-Reply-To: MIME-Version: 1.0 Message-Id: <01082321385803.02716@ice> Content-Transfer-Encoding: 8bit Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk 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