[Haskell] Hierarchical module namespace extension not sufficiently flexible

[Iavor Diatchki]

Hello,

On Sun, 06 Mar 2005 12:21:01 +0000, Duncan Coutts
<duncan.coutts at worc.ox.ac.uk> wrote:
> On Sat, 2005-03-05 at 22:15 +0100, Sebastian Sylvan wrote:
> > On Sat, 05 Mar 2005 17:03:38 +0000, Duncan Coutts > module Graphics.UI.Gtk (
> > >   qualified module Graphics.UI.Gtk.Button as Button,
> > >   ...
> >
> > I like this idea a lot!
> 
> Great. We "just" have to persuade other people around here of the same,
> in particular compiler implementors and the authors of the Hierarchical
> Modules Addenda.
> 
> > It wouldn't break existing stuff (would it?), and it really seems like
> > it should already be in there. I mean if you can import and export
> > modules, it doesn't make sense that qualified imports are allowed but
> > not qualified exports.
> 
> I think the reason it was not added before is down to the fact that
> modules don't really export other modules. They just export other
> modules contents. (Also it was a deliberately conservative extension.)
> 
> Exporting qualified names doesn't really change that, we're just
> exporting the contents of a module but with qualified names.

This seems like quite a significant change from the way the module
system works at the moment (not that this is a bad thing).  Currently
a module can only export "entities",
i.e. the things that names refer to.  It is completely up to the
importing module to decide what names to introduce for the imported
entities.   With this suggestion a module would have to
export not only entities but also hints instructing the importing
module how to name things.
It looks like this could work without too much difficulty.  Presumably
the qualified names
introduced by the importing moudle should be computed by joining the
"as" clause of the import
with the hint that came along with the entity (if any).   
We probably don't want to have multiple hints, so that each entity can
have at most one
hint associated with it.
-Iavor