On Thu, 22 Mar 2001, Judicael Courant wrote:
> Brian Rogoff a écrit :
> > 
> [...]
> > What's the problem with the hack I suggested earlier: put the huge variant
> > (and other duplicated types) in a "pure" .mli file (I hate using .ml for
> > that) and "open"ing it where you need it, once in the .mli file and once in the
> > .ml file? This way you reduce the duplication to two lines.
> > 
> > I know some people are open-phobes, but I find this use of open to be
> > acceptable.
> > 
> 
> As for open-phobes, somebody gave me a good solution a few days ago: you
> can locally define a module with a very short name.
> 
> Example : put your type in my_beautiful_type.mli with constructors Node,
> Leaf, ..., and where you need it do
> 
> module T = My_beautiful_type
> 
> then you can use it with a small overhead of 2 chars per use of a
> constructor of My_beautiful_type: T.Node, T.Leaf, ...
> 
> This is quite elegant IMHO as it makes your code very clear.

Oh yes, this is the common solution in Ada-land for "use-phobes" (their
analogue of open-phobes :) to long package names. They have it a little 
better in that "use" can be in any declarative region so it makes it
easier to find which module things come from. It is possible to do this 
in OCaml with the local module feature but I don't see it as much in code 
I've read.

> As an aside, if you consider applying the same treatment for exceptions
> (also duplicated), you need to put them in a .ml file (not a .mli) as a
> .cmo is needed for linking (an exception actually creates at run-time a
> fresh exception identifier).

Excellent point. However, I don't tend to define that many exceptions, far
fewer than the size of variant types (which easily get tens of
constructors even for a single type) so that duplication doesn't bother me
as much as for types. Still, I should perhaps rethink my aversion to using
a ".ml" as the file holding the duplicated info. 

This entire discussion has the seeds of a few more FAQ entries. Is our
esteemed erstwhile moderator going to do it, or should I take a stab and 
then mail it along?

-- Brian

-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr