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 MAA11659; Tue, 24 Sep 2002 12:37:43 +0200 (MET DST) 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 MAA11755 for ; Tue, 24 Sep 2002 12:37:42 +0200 (MET DST) Received: from fichte.ai.univie.ac.at (fichte.ai.univie.ac.at [131.130.174.156]) by nez-perce.inria.fr (8.11.1/8.11.1) with ESMTP id g8OAbfD04897 for ; Tue, 24 Sep 2002 12:37:42 +0200 (MET DST) Received: from fichte.ai.univie.ac.at (markus@localhost [127.0.0.1]) by fichte.ai.univie.ac.at (8.12.3/8.12.3/Debian -4) with ESMTP id g8OAbfEI007497; Tue, 24 Sep 2002 12:37:41 +0200 Received: (from markus@localhost) by fichte.ai.univie.ac.at (8.12.3/8.12.3/Debian -4) id g8OAbfm4007496; Tue, 24 Sep 2002 12:37:41 +0200 Date: Tue, 24 Sep 2002 12:37:41 +0200 From: Markus Mottl To: Andreas Rossberg Cc: caml-list@inria.fr Subject: Re: [Caml-list] choosing modules at runtime Message-ID: <20020924103741.GB31883@fichte.ai.univie.ac.at> Mail-Followup-To: Andreas Rossberg , caml-list@inria.fr References: <3D90321D.DEFBF3AA@ps.uni-sb.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D90321D.DEFBF3AA@ps.uni-sb.de> User-Agent: Mutt/1.4i Organization: Austrian Research Institute for Artificial Intelligence Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk Andreas Rossberg schrieb am Dienstag, den 24. September 2002: > It's not too bad, just do: > > let (algoA, algoB, algoC) = > if (use algorithm 1) then > (M_1.algoA, M_1.algoB, M_1.algoC) > else if (use algorithm 2) then > (M_2.algoA, M_2,algoB, M_2.algoC) ... > > But admittedly it still is somewhat annoying. Especially if you have many more than three functions. Even worse, if the modules are generated locally, they might involve abstract types not visible outside. It could be legal to combine these functions to generate something that is concrete in another context, but the type system won't allow you to escape scopes, e.g.: module type M = sig type t val v : t val to_int : t -> int end module Func (Arg : M) : M = struct include Arg end let f x = let module Arg = struct type t = int let v = x let to_int x = x end in let module MyMod = Func (Arg) in MyMod.v, MyMod.to_int let _ = let v, to_int = f 42 in print_int (to_int v) The compile will print the following error: File "foo.ml", line 12, characters 2-143: This `let module' expression has type Func(Arg).t * (Func(Arg).t -> int) In this type, the locally bound module name Arg escapes its scope If we could return the whole module "MyMod" instead (much more convenient than returning a tuple anyway), the context (i.e. the one including the abstract type) could be always provided at the place of use. > Such a feature is not impossible to add, but represents a significant > complication of the language that may not be considered worthwhile. It would be interesting to learn, how many people could really need first class modules already now. Then we'd see whether the complication is worthwhile or not. If it doesn't take a Herculean effort to implement them, I'd find them useful enough. Of course, if INRIA has even better things to do implement now, I won't mind... ;-) Best regards, Markus Mottl -- Markus Mottl markus@oefai.at Austrian Research Institute for Artificial Intelligence http://www.oefai.at/~markus ------------------- To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ Beginner's list: http://groups.yahoo.com/group/ocaml_beginners