From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by yquem.inria.fr (Postfix) with ESMTP id DD19DBB81 for ; Sat, 11 Dec 2004 15:30:43 +0100 (CET) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id iBBEUhbJ009195 for ; Sat, 11 Dec 2004 15:30:43 +0100 Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id PAA19724 for ; Sat, 11 Dec 2004 15:30:42 +0100 (MET) Received: from laurie.fmf.uni-lj.si (BSN-77-186-71.dsl.siol.net [193.77.186.71]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id iBBEUejS017291 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Sat, 11 Dec 2004 15:30:42 +0100 Received: from localhost ([127.0.0.1]) by laurie.fmf.uni-lj.si with esmtp (Exim 4.34) id 1Cd8Hp-0001WF-BA; Sat, 11 Dec 2004 15:31:53 +0100 Message-ID: <41BB04D8.60405@andrej.com> Date: Sat, 11 Dec 2004 15:31:52 +0100 From: Andrej Bauer User-Agent: Mozilla Thunderbird 0.8 (X11/20040918) X-Accept-Language: en-us, en MIME-Version: 1.0 To: caml-list Cc: skaller@users.sourceforge.net Subject: Re: [Caml-list] environment idiom References: <9410EC84C0872141B27A2726613EF45D02A52E08@psmrdcex01.psm.pin.safeco.com> <41B97FD7.50309@andrej.com> <1102732237.2611.580.camel@pelican.wigram> In-Reply-To: <1102732237.2611.580.camel@pelican.wigram> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: 7bit X-Miltered: at nez-perce with ID 41BB0493.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Miltered: at concorde with ID 41BB0490.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; andrej:01 andrej:01 caml-list:01 compilers:01 const:01 pointers:01 ocaml:01 ocaml:01 compiler:01 compiler:01 runtime:01 exception:01 idiom:01 functions:01 precisely:01 X-Spam-Checker-Version: SpamAssassin 3.0.0 (2004-09-13) on yquem.inria.fr X-Spam-Status: No, score=0.1 required=5.0 tests=FORGED_RCVD_HELO autolearn=disabled version=3.0.0 X-Spam-Level: It seems that John Skaller and I have different experiences, which is to be expected (unless compilers are like web applications, which I doubt). Clearly, as John and others pointed out, we can usually predict that certain sets of related arguments will be needed frequently, so it makes sense to make an exception to the "pass exactly what is needed" rule and bundle such sets together (as objects/records describing cgi request, host info, database connection, user-session etc). To repeat myself: this is what I did in my second attempt, and the results were better than the first attempt, when I stuck everything in a lookup table. John claims things get complicated in my proposed solution when code is unstable and requires lots of changes. He offers a C/C++ example of the const pointers. I am not convinced that ocaml and C/C++ are comparable in this respect. I habitually abuse the ocaml compiler to tell me precisely what needs to be changed in the following way: I change a type or value definition (say, change the arguments to a function) and keep running the compiler until it reports errors, fixing them as they come up. Had I used conglomerate lookup tables instead of arguments, or any other form of argument passing that the compiler cannot analyze, the compiler would be of little help. You would just postpone the problem to runtime. But don't get me wrong. I definitely agree with John that having 10 arguments to a functions sounds like too many, and something needs to be done in such cases. It's just that in my web application (and I suspect in most) I don't have 10 arguments all over the code, but more like 3 or 4, which is ok. Certainly different types of programs require different solutions. Best regards, Andrej