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
_______________________________________________
Haskell-Cafe mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/haskell-cafe
