Version française
Home     About     Download     Resources     Contact us    
Browse thread
first class modules (was: alternative module systems)
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Xavier Leroy <Xavier.Leroy@i...>
Subject: Re: first class modules (was: alternative module systems)
> a few month ago, Markus Mottl pointed to this mailing list the work by
> Claudio Russo on first class modules. There were no answer about plans to
> implement such a system for OCaml.

Well, it seems like Russo's first-class modules could be added with
relatively little effort, if there is a sufficient need for them.
(In OCaml and also in Luc Maranget's Hevea, I can see the need for
conditionally selecting between several structures having the same
signature; first-class modules give almost this but not quite.)

> As I see it, the main issue is the unification problem < S > = < T >.

Right.  The last time we met, I asked Claudio about type inference
issues for his scheme.  Basically, to "unify" <S> and <T>, you just
check that the module types S and T are equivalent (using the same
notion of equivalence that OCaml currently uses to for checking
compatibility between manifest module type declarations, see the predicate
Includemod.check_modtype_equiv in the OCaml sources).

If <S> and <T> contain value components with non-generalized type
variables, it is necessary to unify them along the way, and Claudio
alluded to potential traps here.  However, I'm not even sure this can
happen at all in OCaml since module types cannot contain n-g type vars
and "pack" requires an explicit module type constraint.

> (as a side effect, we get the local "open ... in ...")

I'm not sure I follow you here.  Did you mean that "open" and "pack"
subsume "let module ... in ..."?  This I agree with.

- Xavier Leroy