Re: [Caml-list] Style and organization of code

[micha <michael.wohlwend@gmx.de>]

Am Thu, 15 Mar 2007 15:01:12 +1100
schrieb skaller <skaller@users.sourceforge.net>:

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