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