🚀 go-pugleaf

On Fri, May 31, 2013 at 03:26:11PM +0900, Francois Berenger wrote:
> On 05/31/2013 02:31 PM, Malcolm Matalka wrote:
> >I know of no such tool, but in counter to your premise: I used to think
> >maintaining a .ml and .mli was foolish, however I no longer do.
> 
[...]


[...]
> > so it's a valuable check that what I think my module does is also
> >what the compiler does.  I also tend to write the .mli first, then write
> >the .ml.  I find it to be a great way to develop.
> 
> I don't.
[...]


I also not always start with the mli-file, but it is a good way
to do it, it#s a good habit.

Why?

Because the interface is designed first.
And the implementation will follow.

Especially in teams, this is a really helpful issue:

  1.: Let the team agree on a interface (mli-file)

  2.: Let the project leader or other person who controls the interface for the modules,
      create the mli-files.
      (the interface for modules && responsibility of certain persons for asertain modules
        => interface between responsibilities)

  3.: Put the mli-files into a certain directory, where they have to live.
      Give read-permissions to all the programmers of the team and write permissions
      to the mli-files only for the person, who is responsible for them.


Then necessarily all programmers of the team know, what the interface is,
and can use these files, but not change them. Creating his/her own mli-files
will not make sense, sooner or later, the official mli-files must be used.

And each programmer can write ml-files in personal style, can write one
or more implementations, which need to fir the interface files.

      
But even if these team-worflow would not be used: deigning the
interface first (thinking about the program in types) can often be helpful
to make the design clear from the beginning.

Of course, especially if things are explored rather experimentally,
for example if there is a new field of topics, where the interface
is NOT clear in advance, starting with the mli-files might be rather
a show stopper.
if things are rather experimentally, starting with the ml-file might
be easier to handle.

So, which way to go depends on the field, on the knowledge of the field,
on how much planning (of interface) is possible or necessary and
if it is done in a team or as a single person.

So, both ways have their advantages and disadvantages.

camlc -i   most often worked for me.

In private projects I not necessarily use mli-files always.
At job I have to use other languages, but the above mentioned
way of read-only mli-files for the programmers of a team
would make sense to me.
This would make interfaces much clearer in the real world,
and IMHO is a good argument for OCaml at work.


If some small programs are one at home,
and the mli files follow the ml-files,
I wonder if they are necessary at all.

I sometimes use modules inside a compilation unit,
and if they clutter the interface too much, use signatures
for these inside-modules, not necessarily for the compilation
unit itself.

But it depends....


If ocamlc could print both: the default signature of the ml-file,
as well as the resulting signature, as delimited by the mli-file,
depending on cli-switches, as well as a diff between the ml-file's
default signature and the signature provided by the mli-file,
this would make handling much easier.
Same call of ocamlc, but just change the switch to get the interface
of the ml-file, the mli-file's signature or the diff between them,
this would be nice.

Something like

  ocamlc -i   foobar.ml   # prints default   sig of foobar.ml
  ocamlc -ii  foobar.ml   # prints resulting sig of foobar.ml (either def.-sig or mli-file-sig)

  ocamlc -id   foobar.ml   # prints diff between default sig and resulting sig (mli-sig if there is a mli-file)
  ocamlc -iid  foobar.ml   # prints diff between resulting sig (mli-sig if there is a mli-file) and default sig


Why ocamlc -ii foobar.ml, if 'cat foobar.mli' or 'ocamlc -i foobar.mli' would
give the same result?
Just because the handling would be unified: same command, same filename, just a
different switch.


Hope, this does make some sense not only for me ;-)


Ciao,
   Oliver

-- 
Caml-list mailing list.  Subscription management and archives:
https://sympa.inria.fr/sympa/arc/caml-list
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs