[Haskell-cafe] Packages and modules

[Brian Hulley]

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