Simon Peyton-Jones wrote:
Simon and I have been thinking about fixing this, and we think we might actually do so for GHC 6.6. Your message provoked us to write up the design. It's here http://hackage.haskell.org/trac/ghc/wiki/GhcPackages Feedback welcome
It's worth reading the old threads; for example
http://www.haskell.org//pipermail/libraries/2005-August/004281.html But there are many others!
[from wiki]
ghc -c -package P1 M1.hs ghc -c -package P2 M2.hs ...compile other modules... ghc -o app M1.o M2.o ... -package P1 -package P2
I don't think this solves the whole problem. Suppose M1 needs to use A.B.C from P1 *and* A.B.C from P2, then it would need to be compiled with P1 and P2, and there is no way (from the part of the proposal in this section alone) to distinguish between these packages from within M1 itself if we're still to be limited by the import A.B.C syntax. It only seems to address the problem of app needing to use M1 and M2 but not A.B.C directly where M1 only uses P1 and M2 only uses P2. [from wiki]
import Packages.Gtk-1_3_4.Widget.Button
Allowing package aliases in the source could make this easier to type and avoid the necessity to capitalise and change underscores to dots: package gtk-1_3_4 as Gtk or package gtk as Gtk -- use the current version of gtk or if package directive is omitted an import Xyz/Mod is equivalent to: package xyz as Xyz -- initial letter capitalised import Xyz/Mod and making the package part of the module id explicit prevents ambiguity problems (David House's idea) though at the expense of using more syntax ie import Widget.Button from Gtk or import Gtk/Widget.Button -- instead of grafting In all cases I think it would be an absolute disaster to allow modules to be imported without an explicit package id because this would defeat the whole purpose of having a simple per-package namespace for modules and wouldn't allow the reader of source to know which packages it's referring to. Of course all code would need to be changed, but this could be accomplished by a conversion program which, given a list of packages and alias names, would just recursively traverse a source directory replacing imports and module exports by package directives and the fully qualified name of each module. [from wiki]
Optional extra: grafting
ambiguity ( http://www.haskell.org//pipermail/haskell-cafe/2006-June/016317.html ) The use of / instead of . (or from) gives the advantage of grafting in terms of succinct qualified module names without this ambiguity. Summary of my suggestions: 1) All module names would be of the form PackageAlias/ModId 2) package directives in the source bind aliases to actual packages 3) version number or package directive can be omitted when we are only interested in using the current version of that package 4) Package aliases have their own namespace 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