* RE: [Caml-list] about typedefs... (was: duplication implementation/interface)
@ 2001-03-22 19:15 Manuel Fahndrich
0 siblings, 0 replies; 2+ messages in thread
From: Manuel Fahndrich @ 2001-03-22 19:15 UTC (permalink / raw)
To: Olivier Andrieu, caml-list
Yes, the reason it is needed is to be able to export from a module both
a type sharing constraint, and at the same time the concrete type
representation.
module type I = sig
module M : J
type t = M.s = { foo : int }
end
Such a description gives you two pieces of information. M.s = t and also
the representation of this type.
Regards,
Manuel
-----Original Message-----
From: Olivier Andrieu [mailto:andrieu@oxygene.ijm.jussieu.fr]
Sent: Thursday, March 22, 2001 3:17 AM
To: caml-list@inria.fr
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
-------------------
To unsubscribe, mail caml-list-request@inria.fr. Archives: http://caml.inria.fr
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: [Caml-list] recursive modules redux, & interface files
@ 2001-03-22 0:22 Brian Rogoff
2001-03-22 10:26 ` [Caml-list] duplication implementation/interface Judicael Courant
0 siblings, 1 reply; 2+ messages in thread
From: Brian Rogoff @ 2001-03-22 0:22 UTC (permalink / raw)
To: Patrick M Doane; +Cc: John Max Skaller, caml-list
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
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: [Caml-list] duplication implementation/interface
2001-03-22 0:22 [Caml-list] recursive modules redux, & interface files Brian Rogoff
@ 2001-03-22 10:26 ` Judicael Courant
2001-03-22 11:16 ` [Caml-list] about typedefs... (was: duplication implementation/interface) Olivier Andrieu
0 siblings, 1 reply; 2+ messages in thread
From: Judicael Courant @ 2001-03-22 10:26 UTC (permalink / raw)
To: Brian Rogoff; +Cc: caml-list
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.
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).
Judicaël
--
Judicael.Courant@lri.fr, http://www.lri.fr/~jcourant/
(+33) (0)1 69 15 64 85
"Montre moi des morceaux de ton monde, et je te montrerai le mien"
Tim, matricule #929, condamné à mort.
http://rozenn.picard.free.fr/tim.html
-------------------
To unsubscribe, mail caml-list-request@inria.fr. Archives: http://caml.inria.fr
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: [Caml-list] about typedefs... (was: duplication implementation/interface)
2001-03-22 10:26 ` [Caml-list] duplication implementation/interface Judicael Courant
@ 2001-03-22 11:16 ` Olivier Andrieu
0 siblings, 0 replies; 2+ messages in thread
From: Olivier Andrieu @ 2001-03-22 11:16 UTC (permalink / raw)
To: caml-list
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
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2001-03-22 19:15 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2001-03-22 19:15 [Caml-list] about typedefs... (was: duplication implementation/interface) Manuel Fahndrich
-- strict thread matches above, loose matches on Subject: below --
2001-03-22 0:22 [Caml-list] recursive modules redux, & interface files Brian Rogoff
2001-03-22 10:26 ` [Caml-list] duplication implementation/interface Judicael Courant
2001-03-22 11:16 ` [Caml-list] about typedefs... (was: duplication implementation/interface) Olivier Andrieu
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).