Frank A. Christoph wrote:
>
> >Standard ML does not allow this. One important aspect of the SML module
> >system actually is its strong separation from the core language.
>
> Not that old saw again...! Ocaml separates the two as well.
Well, the new let-module feature undermines the separation quite a bit,
because any expression can now contain arbitrary module code -- the
module system no longer rests on top of the core language.
> I imagine that it could be translated into SML along these lines
> (excuse my rusty SML):
>
> structure M = struct ... val y = ref <something> ... end;
> structure X =
> struct
> fun f(x,y) = M.y := y; ... !M.y ...
> end;
>
> Or maybe not. I'm not sure of the extent of the feature, but I get the
Not really. First of all, f will not be re-entrant (e.g. recursion won't
work). You had to save and restore the previous value. But that's not
all: consider the following (admitedly contrieved) code for example
let rec f x = let module M = struct exception E end
in match x with M.E -> ()
| _ -> f M.E
A call like f(some_exn) will not terminate because M.E is different on
each recursion. You can observe similar effects using references. The
point here is that modules (and all the generative objects in it, like
references, exceptions, modules, etc.) are really created at runtime,
while without the let-module feature, all module instances are
determined at compile time.
Also, the main motivation for introducing it was to allow functor
applications that depend on polymorphic type variables. I think these
cannot be translated (as far as typing is concerned).
(In case somebody is still interested. But this has far left the scope
of the Haskell list now.)
> You're right, though. I meant expression-local imports, like
>
> local open M
> in ...
\begin{nitpicking}
You probably mean
let open M
in ...
\end{nitpicking}
And I agree, these are very useful sometimes (although I wouldn't call
that import).
- Andreas
