something akin to Java's "package" in libraries

[Simon Marlow]

> I vaguely recall a brief discussion of this long ago, but=20
> don't see any
> reference to it on the libraries web page.  What I had in mind is
> something like:
>=20
>=20
> > package Graphics.GL
> > module Foo (...)
> >    where
> >=20
> > import X
> > import Bar.Y
> > import Z
> > ...
>=20
> where the first conversion is
>=20
>   module-name <- package-name ++ "." ++ module-name
>=20
> the larger issue would be how to convert imports to qualified=20
> imports (and
> module exports to qualified exports).  i think (only my opinion) that
> something like:
>=20
> import X
>=20
> should be qualified to
>=20
> import Graphics.GL.X as X
>=20
> unless Graphics.GL.X doesn't exist, in which case it gets defaulted to
>=20
> import X

This is an interesting suggestion.  However, I'd like to see if people =
really think that writing out the full module names is really a problem =
in practice - in my (limited) experience with the hierarchical libraries =
so far I don't mind writing out the full module names in import lists at =
all, and I even quite like to see the module names written out in full.

On the other hand, I haven't been working with any modules that go more =
than 3 deep in the hierarchy, so I'd like to hear feedback from someone =
writing a library with multiple modules that lives deep in the hierarchy =
(Sven - perhaps you qualify with Graphics.Rendering.OpenGL.GL?).

But I guess the packages concept helps when you want to graft a subtree =
of modules from one place in the hierarchy to another, right?

I must admit I don't like the idea of defaulting to importing X if =
<package>.X doesn't exist, I'd prefer the two cases to be syntactically =
distinct.  Perhaps the convention should be that '.X' means =
'<package>.X', and plain X is left alone.

(oh, and there have been various other suggestions along these lines - =
have a look back through the mailing list archives).

Cheers,
	Simon