Changes between Version 9 and Version 10 of Commentary/Packages/GhcPackagesProposal


Ignore:
Timestamp:
Jul 4, 2006 11:21:05 AM (8 years ago)
Author:
guest
Comment:

clarify that this is planned functionality, add another problem example

Legend:

Unmodified
Added
Removed
Modified
  • Commentary/Packages/GhcPackagesProposal

    v9 v10  
    2323The authors of packages P1 and P2 didn't need to know about each other, and don't need to choose globally unique module names. 
    2424 
    25 The fundamental thing GHC needs to do is to include the package name into the names of entities the package defines.  That means that when compiling a module M you must say what package it is part of: 
     25The fundamental thing GHC will need to do is to include the package name (and version) into the names of entities the package defines.  That means that when compiling a module M you must say what package it is part of: 
    2626{{{ 
    2727  ghc -c -package package-name P1 C.hs 
     
    3838 * Then, you can use the {{{-hide-package}}} flag to hide an otherwise-exposed package, and the {{{-package}}} flag to expose an otherwise-hidden package. 
    3939 
    40 By manipulating these flags, you can expose package P1 when compiling module M (say), and expose P2 when compiling module N.  Then M and N could both import module A.B.C, which would come from P1 and P2 respectively. But: 
     40When GHC incorporates package names in exported symbols, you will be able to expose package P1 when compiling module M (say), and expose P2 when compiling module N by manipulating these flags.  Then M and N could both import module A.B.C, which would come from P1 and P2 respectively. But: 
    4141 * What if you wanted to import A.B.C from P1 and A.B.C from P2 into the ''same'' module? 
     42 * What if you want to only replace ''parts'' of P1 (e.g., you want to use an updated version of a module in {{{base}}})? 
    4243 * Compiling different modules with different flags in a way that affects the ''semantics'' (rather than, say, the optimisation level) seems undesirable. 
    4344 * To support {{{--make}}} in this situation we'd need to allow {{{-package}}} flags in the per-module {{{OPTIONS}}} pragmas, which isn't currently supported.  ({{{ghc --make}}} already gathers those options together for the link step.)