From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id KAA06818 for caml-red; Thu, 11 Jan 2001 10:25:58 +0100 (MET) Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id WAA32045 for ; Wed, 10 Jan 2001 22:34:47 +0100 (MET) Received: from nef.ens.fr (nef.ens.fr [129.199.96.32]) by nez-perce.inria.fr (8.11.1/8.10.0) with ESMTP id f0ALYkT18346 for ; Wed, 10 Jan 2001 22:34:46 +0100 (MET) Received: from clipper.ens.fr (clipper-gw.ens.fr [129.199.1.22]) by nef.ens.fr (8.10.1/1.01.28121999) with ESMTP id f0ALYkM17362 ; Wed, 10 Jan 2001 22:34:46 +0100 (CET) Received: from localhost (frisch@localhost) by clipper.ens.fr (8.9.2/jb-1.1) id WAA06036 ; Wed, 10 Jan 2001 22:34:46 +0100 (MET) Date: Wed, 10 Jan 2001 22:34:45 +0100 (MET) From: Alain Frisch To: Claudio Russo cc: Brian Rogoff , Caml list Subject: first class, recursive, mixin modules (was: RE: first class modules) In-Reply-To: <112C6E8A1B25D34BB27D48D2FD2E96CFC9DED1@TVP-MSG-02.europe.corp.microsoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: weis@pauillac.inria.fr On Wed, 10 Jan 2001, Claudio Russo wrote: > Moscow's recursive modules have the advantage that they > leverage many of the concepts already existing in the Definition. If I > recall correctly, they require one new kind of semantic object, a simple > generalisation of enrichment, and two new syntactic constructs with > associated evaluation and typing rules. Current main drawbacks: heavy > syntax requiring forward declarations, > no support for cross-compilation-unit recursion and recursion on module > terms requires a dynamic check for each > forward reference (this is because the implementation imposes no > restriction on whether the recursion is safe or not, forcing a dynamic > check for definedness). Are there real examples using recursive modules with these restrictions ? You can always define everything outside the structures (or in the first one), then copy the types and values in the structures. Of course, you loose the modularity of definitions, but with recursive modules as in MosML, you loose the static typing for the module language (Bind exceptions) and also the modularity (different source files; separate compilation). If you accept runtime checks, the solution adopted in the OCaml compiler to break the circle of dependencies between the Core and Module type checkers (forward declaration with a reference updated when the definition is available) has the advantage of retaining separate compilation. Back to first class packaged modules: a very useful feature for runtime configuration of applications would be the possibility to load the packages from the disk/network (that is, dynamic loading; the signature of trusted packages can be checked as in the Dynlink module). About mixins: what is the proposed dynamic semantic ? I guess the evaluation of the mixins, which can have side effects or depend on the environment, is done when then composition yields a fully defined structure. But this operation involves a reordering of the definitions, so it may be non trivial to predict the evaluation order of the different fields. Is there a requirement for the ordering to be compatible when possible with the order of definition for values/submodule in each mixin of the composition ? -- Alain Frisch