Version française
Home     About     Download     Resources     Contact us    
Browse thread
[Caml-list] choosing modules at runtime
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ 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