From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: * X-Spam-Status: No, score=1.3 required=5.0 tests=SPF_FAIL autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from discorde.inria.fr (discorde.inria.fr [192.93.2.38]) by yquem.inria.fr (Postfix) with ESMTP id 46549BC0A for ; Thu, 15 Mar 2007 10:03:08 +0100 (CET) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by discorde.inria.fr (8.13.6/8.13.6) with SMTP id l2F937cY031075 for ; Thu, 15 Mar 2007 10:03:08 +0100 Received: (qmail invoked by alias); 15 Mar 2007 09:03:06 -0000 Received: from p54A31C4A.dip0.t-ipconnect.de (EHLO localhost) [84.163.28.74] by mail.gmx.net (mp025) with SMTP; 15 Mar 2007 10:03:06 +0100 X-Authenticated: #20477425 X-Provags-ID: V01U2FsdGVkX19jttdNsdVjxi6CogQ5DAYgynED0lN0t3NF+PxoFV 7zxtLx1ZddFj6n Date: Thu, 15 Mar 2007 10:03:05 +0100 From: micha To: caml-list@yquem.inria.fr Subject: Re: [Caml-list] Style and organization of code Message-ID: <20070315100305.2712ee03@localhost> In-Reply-To: <1173931272.31293.15.camel@rosella.wigram> References: <45F87661.4020504@softhome.net> <1173931272.31293.15.camel@rosella.wigram> X-Mailer: Sylpheed-Claws 2.6.0 (GTK+ 2.8.20; i486-pc-linux-gnu) X-Face: S)[vu%Bha1d&ej9GfwAq~7C}A,y[B.uS}+D6'hb~xPwsxymw$fnCOaMe<*bnUajSBR_m?R@V3;iX8[A}z`.%pEQ1r7iZhN8#ktTCBQ}&mkx>=RH&l|l6\]NZI@ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Miltered: at discorde with ID 45F90BCB.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; ocaml:01 coupling:01 enclosing:01 semantics:01 semantics:01 ocaml's:01 'open:01 dependencies:01 ocaml:01 compiler:01 mli:01 sig:01 struct:01 mli:01 sourceforge:01 Am Thu, 15 Mar 2007 15:01:12 +1100 schrieb skaller : > On Wed, 2007-03-14 at 17:25 -0500, ian wrote: > > I'm looking for a guidebook or just some rules of thumb on how to > > organize my OCaml code. > > > But that would make the definition of solveHardProblem really long > > -- several screens of text -- which I've been taught to avoid. > > Yeah, this is a problem with functional programming .. i have > functions that are hundreds of lines long. > > Generally you want to factor out functions with minimal coupling > to the enclosing function's environment, and leave them in > if they're heavily coupled. > > Furthermore if that helper is reasonably general OR it has > some semantics which are separately understandable .. you can > put that function in a separate file for additional decoupling. > > > Is it wrong to use a module > > to hide those functions if the module signature will contain only > > that of solveHardProblem? > > That's the normal thing to do. > > Furthermore if that helper is reasonably general OR it has > some semantics which are separately understandable .. you can > put that function in a separate file for additional decoupling. > > This has the downside that Ocaml's namespace management is weak, > so your function is now fully public. > > But smaller modules are more pleasing and easier to manage, > so it is probably worth while. > > In particular if you use 'open Module' a lot, then the > dependencies both ON and OF that module are more refined > and explicit. This is also a reasonable first order approximation > to measuring the 'coupling' between components. > > > And say you DO choose to use a module... The OCaml documentation > > says that the compiler can automatically infer the signature > > without the need to create a .mli file for it. Does anyone > > actually use that feature in practice, or is creating a sig > > hard-wired to the act of creating a struct? > > I personally never do this: there is always an mli file for > every ml file -- even if the build script makes it by copying > the mli file. >