loading modules

[Mark P Jones]

|  > * When you evaluate an expression in the interpreter, it has
|  >   to use some symbol table for looking up the ids you use. What
|  >   symbol table does it use?  The only credible alternatives are:
|  >
|  >     * The export list of the "current module" (see :module command)
|  >     * The symbol table of the "current module"
|  >
|  > Hugs uses the latter (which seems more useful) but you might reasonably
|  > expect Hugs to use the export list and wonder why Hugs doesn't seem to
|  > implement abstract data types correctly when you do experiments from
|  > the command line.
|
| This begs the question of exactly what it means to "load
| modules". The Hugs documentation AFAIK seems to assume it's
| self-evident. But, as the "not a bug it's a feature" message
| above makes clear, it isn't, even when just a single module
| is loaded. I would have thought module loading could be
| defined in terms of something *in* Haskell (as did presumably
| the bug reporters the message is responding to); but at the
| moment the best that could be said is that module loading is
| an undocumented hack.

I disagree.  The behavior is documented (see the description
of the :module command), although I'll agree that it is not
labored to the extent that you might have liked.

If the Hugs prompt indicates that you are *in* a module M, then
the symbols that are in scope are precisely those symbols that
are in scope *in* the module M.  The details of an "abstract
data type" are hidden only in clients of that type, and not
within the implementation.  If you want to observe the effects
of working with an abstract datatype that is defined in a module
M, then you can define a new client module something like the
following

  module ClientOfM where
  import M

and then do a :load ClientOfM to put yourself in the desired
context.  This is not a bug/feature issue as you describe it; it
is how Hugs reflects the differences between the implementation
and the clients of an ADT.  In fact there are important concepts
to learn from the fact that some expressions will be accepted
when the current module is M, but rejected when you switch to
ClientOfM.

One could imagine extending an interpreter like Hugs with a
more complicated :module command that allows users to specify
on which side of the module boundary they wanted to be.  For
example:
  :module <M
might put you inside M, while
  :module >M
might put you just outside with only exported entities in scope.
I don't think the extra complexity is justified, because the same
thing can be accomplished, without having to step outside the
language, by defining modules like ClientOfM.  And indeed, when
you do that, you have much more flexibility, for example, to import
multiple modules, to use hiding, selective, or qualified imports,
and even to add extra definitions for use in testing or experiments.
And by capturing this in a persistent form (i.e., in a file), you
can use the same thing many times, share it, etc...

The ability to execute an expression within the context (or the
"symbol table" as the poster you reference calls it) of the current
module is particularly useful for debugging or otherwise working
with the internals of a module.  The other alternative that was
suggested (i.e., that expressions be evaluated in the context of
the export list only of the module named in the prompt) would not
support this kind of behavior and would, in my opinion, be a weaker
design.

All the best,
Mark