Robert Dockins wrote:
On Sunday 25 June 2006 05:16 am, Brian Hulley wrote:
[snip]
I'm wondering: would it not be easier to just make it that the
package name is prepended to the hierarchical module name, so the
modules would instead be called by the names P.Data.Foo and
Q.Data.Bar?
[snip discussion of this idea]
The idea of improving the module system has been discussed a number
of times before. Here is a thread started by a suggestion from the
simons which generated a fair bit of discussion:
http://www.haskell.org/pipermail/libraries/2003-August/001310.html
I'm not sure whatever became of this idea; discussion seemed to sort
of reach a consensus, and then nothing happened.
Thanks for the link...
At the risk of being a "devil's advocate" I think the above idea is too
flexible and overly complicated. Imho it would be like trying to have a
conversation with a group of people where each person is constantly jumping
about, changing their name and appearance, and might be replicated in
several places at once... :-)
I'd have thought all that's needed is a nice simple "cathedralish" design
where each module knows its globally unique place and just stays there
forever so that it's easy to develop and share code which uses it. (Could
Java be seen as a proof of concept here? )
Package aliases in the code would then make it easy to upgrade to the latest
package eg
package Graphics.Rendering.OpenGL-8-9 as OpenGL
import OpenGL/GL.Bitmaps
In a sense the package alias idea is a little bit like grafting, except the
aliasing is specified in the source code instead of somewhere else. Perhaps
package aliases could even be inherited from "parent" modules...
The module "grafting" mechanism always seemed kind of nice to me. I
think some of the problems discussed in this thread could be by using
cabal, especially to specify the graftings expected for compilation.
You'd then have to keep the Cabal info in sync with the source. At the
moment I can just use ghc --make and don't need to know about Cabal at all
unless I want to distribute a package (or install one).
It seems like grafting can give a plausible story for dealing with
dynamicly loaded code, which is a nice bonus.
I hadn't thought of dynamically loaded code though...
Regards, Brian.
--
Logic empowers us and Love gives us purpose.
Yet still phantoms restless for eras long past,
congealed in the present in unthought forms,
strive mightily unseen to destroy us.
http://www.metamilk.com
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
