[Haskell] Hierarchical module namespace extension not sufficiently flexible

Iavor S. Diatchki diatchki at cse.ogi.edu
Fri Dec 17 14:49:16 EST 2004


Duncan Coutts wrote:

>So while we would like to be able for users to do this:
>>import Graphics.UI.Gtk
>>... Button.setLabel ...
I don't think you can do things like this with the current module system.
One possible extension that might solve this problem is to allow partial 
qualified names,
i.e. a qualified name only specifies enough of the _ending_ of the full 
qualified name
to make it unambiguous.  I think this is more or less compatable (of 
course it would invalidate some
programs but not a lot) as the current behavior is simply the special 
case where
we specify the whole name.

(Off the top of my head) I think this is quite easy to implement.  For 
example in
one of the Haskell front-ends we have here at OGI (Programatica), there is
a "resolve" pass that replaces qualified names by the origianl names 
they refer to.
During this pass we can detect ambiguous or undefined names.  All one would
have to do is modify the lookup function to check for suffixes rather 
then equality.
I am not sure how other implementations work, but I'd imagine one would 
have to
do something similar.

>Ps there's a oddity I found where if you say:
>>module Foo (
>>  module Bar
>>import qualified Bar
>then module Foo exports precisely nothing. But there's no error or warning.
This is the correct behaviour (at least according to the spec).  The 
meaning of "module" exports
is not as simple as one might expect.  For details check out the report, 
for even more details
you could take a look at "A Formal Specification of the Haskell 98 
Module System".
I agree that a warning in such situations may be nice.


More information about the Haskell mailing list