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=0.0 required=5.0 tests=none autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by yquem.inria.fr (Postfix) with ESMTP id BDD95BC0A for ; Thu, 15 Mar 2007 05:01:20 +0100 (CET) Received: from ipmail02.adl2.internode.on.net (ipmail02.adl2.internode.on.net [203.16.214.141]) by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id l2F41INS011048 for ; Thu, 15 Mar 2007 05:01:19 +0100 Received: from ppp244-227.lns3.syd6.internode.on.net (HELO [192.168.1.201]) ([121.44.244.227]) by ipmail02.adl2.internode.on.net with ESMTP; 15 Mar 2007 14:31:16 +1030 X-IronPort-AV: i="4.14,286,1170595800"; d="scan'208"; a="97763257:sNHT24067757" Subject: Re: [Caml-list] Style and organization of code From: skaller To: ian Cc: caml-list@inria.fr In-Reply-To: <45F87661.4020504@softhome.net> References: <45F87661.4020504@softhome.net> Content-Type: text/plain Date: Thu, 15 Mar 2007 15:01:12 +1100 Message-Id: <1173931272.31293.15.camel@rosella.wigram> Mime-Version: 1.0 X-Mailer: Evolution 2.8.1 Content-Transfer-Encoding: 7bit X-Miltered: at concorde with ID 45F8C50E.001 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 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. -- John Skaller Felix, successor to C++: http://felix.sf.net