Browse thread
[Caml-list] choosing modules at runtime
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
| Date: | -- (:) |
| From: | Markus Mottl <markus@o...> |
| Subject: | Re: [Caml-list] choosing modules at runtime |
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