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: Olivier Andrieu <andrieu@o...>
Subject: Re: [Caml-list] about typedefs... (was: duplication implementation/interface)
 Judicael Courant [Thursday 22 March 2001] :
 > 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.

There's something I've been wondering about type definitions :

In type definitions, you can specify type equation and representation.
 - when none is specified, the defined type is abstract ;
 - when an equation is given, you get an alias of an already existing
type ;
 - with a representation, a new variant or record is defined.

But it is possible to use both, so that you get an alias of an already
defined variant and record but with the fields or constructors attached to
the new type. 

It don't really see the point of such a definition : now the type
representation is in 4 different places, and the only gain I see is
that you don't have to prefix the fields names with a module
path. That's no big deal since you can redefine the module with a short
name (one letter).

So, is this form of type definitions actually used, does it have another
purpose besides this namespace issue ?

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