Version française
Home     About     Download     Resources     Contact us    
Browse thread
[Caml-list] recursive modules redux, & interface files
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Brian Rogoff <bpr@b...>
Subject: Re: [Caml-list] recursive modules redux, & interface files
On Wed, 21 Mar 2001, Patrick M Doane wrote:
> I don't see that it makes much of a difference. Besides, the reason it
> hasn't worked well for me is that inevitably I want to add some
> functions to the module that has the variant type. For example, pretty
> printers. The next compromise is to continue the path without a .mli file
> until I don't want some of these utilities to be exported.  In the end,
> I'm back to the source of the problem, having to duplicate a large variant
> type.

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.

-- Brian

> 
> On Thu, 22 Mar 2001, John Max Skaller wrote:
> 
> > Patrick M Doane wrote:
> >  
> > > For projects that I've worked on that have huge variant types, I have
> > > typically placed the variants in a module by themselves with no .mli file.
> > > This technique hasn't worked too well for me in practice and is still
> > > annoying for the smaller variants.
> > 
> > 	Try placing them in a .mli file instead (no ml file).
> > 
> > -- 
> > John (Max) Skaller, mailto:skaller@maxtal.com.au
> > 10/1 Toxteth Rd Glebe NSW 2037 Australia voice: 61-2-9660-0850
> > checkout Vyper http://Vyper.sourceforge.net
> > download Interscript http://Interscript.sourceforge.net
> > 
> 
> -------------------
> To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr
> 

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