Re: [Caml-list] two unrelated questions

[Jacques Garrigue <garrigue@kurims.kyoto-u.ac.jp>]

From: Brian Rogoff <bpr@best.com>

> I think the real beauty of this local module feature is that it allows
> things like  a local open, which may make open more palatable to
> open-phobes.
> 
> though I take it that these kinds of tricks weren't the original goal of
> the feature. Still, the syntax is light so these are very painless
> workarounds even without the P4 prettification. 

Indeed, I think they were not the original goal.
As I heard it from Xavier, this was mostly intended to allow local
instances of functors.

Particularly, local exception definitions are one of the rare features
present in SML and absent in Caml, and that some SML developpers think
that Caml is right about :-)
That is, defining local exceptions (and local types also) is a very
fine way to shoot oneself in the foot. You end up having plenty of
exceptions (or types) with the same name (impossible to distinguish at
toplevel), but incompatible. For types, this is still ok since the
type checker does not allow it to escape its scope; which can give you
funny errors:

  # let module M = struct type t = A | B end in M.A;;
  This `let module' expression has type M.t
  In this type, the locally bound module name M escapes its scope

For exceptions, logically a locally defined exception escaping its
scope should be a fatal error, but this is not the case (cannot be
really enforced). So you can end up at toplevel getting an exception
of an unknown name, impossible to catch. (This is the problem SMLers
cite most often).

On the other hand, I perfectly agree with you that opening a module
locally is something you want to do often, and causes no safety
problem at all.
That's one of the reasons I think mixing it with let module is not
good: the let module feature is theoretically subtle, and should be
used with care, while a let open construct does nothing (just changes
the static scope), and does not require the same caution.

Cheers,

Jacques Garrigue
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr