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

[Tom <tom.primozic@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1898 bytes --]

On 14/03/07, ian <fist_187@softhome.net> wrote:
>
> I'm looking for a guidebook or just some rules of thumb on how to organize
> my
> OCaml code.
>
> One example:
>
> Say I have a function called "solveHardProblem".


So, this is the first place for change. OCaml functions, values, types, and
exceptions are usually not named lowerUpperCase, but words_with_underscores
- it is somewhat disfunctional for us coming from "other" parts of the world
(typing _ includes pressing the Shift key) but so is typing uppercase letter
- there are no other alternatives. Anyways, better stick to the convention.

solveHardProblem relies on
> several helper functions, which are not going to be useful to any other
> functions in the program.  So, my first instinct would be to define all
> the
> helpers using let blocks within the definition of solveHardProblem.
>
> But that would make the definition of solveHardProblem really long --
> several
> screens of text -- which I've been taught to avoid.  Is it wrong to use a
> module
> to hide those functions if the module signature will contain only that of
> solveHardProblem?


No.

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?


Hm... well... I mean, the compiler can actually infer things for you, but
this simply means that you don't NEED to include a signature - it's not a
compile time error if you omit it. But the comiler will assume that you want
all the values (including functions) and types from this module to be
exported. So .mli signatures are actually used for limiting exports. Exactly
what you're trying to do.

Or you can simply define helper functions, and never use them.

- Tom

[-- Attachment #2: Type: text/html, Size: 2619 bytes --]