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


Ignore:
Timestamp:
Jul 4, 2006 3:12:09 PM (8 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"?