From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id GAA16624; Wed, 21 Mar 2001 06:10:26 +0100 (MET) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f 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 GAA16312 for ; Wed, 21 Mar 2001 06:10:25 +0100 (MET) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by nez-perce.inria.fr (8.11.1/8.10.0) with ESMTP id f2L5ANj06567 for ; Wed, 21 Mar 2001 06:10:24 +0100 (MET) Received: from localhost (patrick@localhost) by fledge.watson.org (8.11.1/8.11.1) with SMTP id f2L5AAZ87444; Wed, 21 Mar 2001 00:10:10 -0500 (EST) (envelope-from patrick@watson.org) Date: Wed, 21 Mar 2001 00:10:09 -0500 (EST) From: Patrick M Doane To: Chris Hecker cc: caml-list@inria.fr Subject: Re: [Caml-list] recursive modules redux, & interface files In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk I agree that checking interface/implementation of modules could be improved. 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. A reasonable modification to the language would allow a module expression to not include type definitions when they are defined in the module type and include their type information. This would mean that module X : sig type t = int end = struct end would be accepted, but module X : sig type t end = struct end would be rejected because the abstract field 't' is required but missing. Would this proposal address all the issues you had in mind? Patrick Doane On Tue, 20 Mar 2001, Chris Hecker wrote: > > > There are only two options. [And non-local classes are _always_ extern] > > This is not so in Ocaml: you may wish to provide access to a component > > such as a function with a type more constrained than the actual > > implementation. > > Yes yes yes, I know this. I'm saying I understand why I need to type > stuff if there's a difference betwen the .ml and .mli versions (hiding > stuff, restricting stuff, abstracting stuff), and that's fine. I'm > asking why I need to retype stuff if it's identical. Check out some > of the source code in the compiler, or any ocaml project I've seen > (the ICFP winners, whatever). There are tons of really huge variants > that are just duplicated in mli and ml. That seems bad, for the same > reason that typing a C++ function declaration 2 times is bad. > > Chris > > > ------------------- > 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