Changes between Version 11 and Version 12 of Commentary/Packages/GhcPackagesProposal


Ignore:
Timestamp:
Jul 4, 2006 3:12:09 PM (9 years ago)
Author:
simonpj
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • Commentary/Packages/GhcPackagesProposal

    v11 v12  
    55A vexed question in the current design of Haskell is the issue of whether a single program can contain two modules with the same name.  Currently that is absolutely ruled out, and as a result packages are fundamentally non-modular: every package must use a distinct space in the global namespace.
    66
    7 There are two quite separate issues, addressed in the following two sections.  But before we start, note that we take for granted the following
    8  * Each package has a globally-unique name, organised by some social process
    9 This assumption is deeply built into Cabal, and lots of things would need to change if it wasn't met.
     7There are two quite separate issues, addressed in "Question 1", "Question 2" below.  First we give assumptions.
     8
     9== Assumptions ==
     10
     11Before we start, note that we take for granted the following
     12 * Each package has a globally-unique name, organised by some social process.  This assumption is deeply built into Cabal, and lots of things would need to change if it wasn't met.
     13
     14 * Module names describe ''purpose'' (what it's for, e.g. {{{Data.Bits}}}), whereas package names describe ''provenance'' (where it comes from, e.g. {{{"gtkhs"}}}).  We should not mix these two up, and that is a good reason for not combining package and module names into a single grand name.  One quite frequently wants to globally change provenance but not purpose (e.g. compile my program with a new version of package "foo"), without running through all the source files to change the import statements.
     15
    1016
    1117== Question 1: Can two different packages contain a module with the same module name? ==
     
    5460The exact syntax is unimportant. The important thing is that the programmer can specify the package in the source text.
    5561
    56 
    57 == Alternative: the Packages space ==
    58 
    59 Perhaps every (exposed) module from every (installed) package should always be available via an import like
    60 {{{
    61    import Packages.Gtk-1_3_4.Widget.Button
    62 }}}
    63 That is, the module is name by a fully-qualified name involving its package name (already globally unique). 
    64 
    65 (Tiresome side note: to make the package id look like a module name we may have to capitalise it, and change dots to underscores.  And that could conceivably make two package names collide.)
    66 
    67 == Alterative: grafting ==
    68 
    69 Some kind of 'grafting' or 'mounting' scheme could be added, to allow late binding of where in the module tree the is brought into scope.  One might say
    70 {{{
    71         ghc -c Foo.hs -package gtk-2.3=Graphics.GTK
    72 }}}
    73 to mount the {{{gtk-2.3}}} package at {{{Graphics.GTK}}} in the module name space.  Outside
    74 the package one would need to import {{{Graphics.GTK.M}}}, but within the package one just imports {{{M}}}.  That way the entire package can be mounted elsewhere in the namespace, if desired, without needing to change or recompile the package at all.
    75 
    76 This would allow a single module to import modules from two different packages that happened to use the same name.  It's not strictly a necessary feaure.  If you want to
    77  * import module A from package P, and
    78  * import module A from package Q into a single module M of a program,
    79 
    80 you can always do this:
    81  * make a new module AP, that imports A and re-exports it all;
    82  * compile AP with package P visible and Q hidden
    83  * ditto for AQ
    84  * make M say "import AP; import AQ".
    85 
    86 
    87 The exact details of the mounting scheme, and whether it is done at
    88 build time, at install time, or at compilation time, or all of the
    89 above, are open to debate.  We don't have a very fixed view.
    90 
     62An open question: if A.B.C is in the package being compiled, and in an exposed package, and you say {{{import A.B.C}}}, do you get an error ("ambiguous import"), or does the current package override.  And if the former, how can you say "import A.B.C from the current package"?