Changes between Version 2 and Version 3 of Commentary/Packages/PackageMountingProposal


Ignore:
Timestamp:
Oct 26, 2006 3:08:07 AM (9 years ago)
Author:
Frederik
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • Commentary/Packages/PackageMountingProposal

    v2 v3  
    11=== Proposal for Package Mounting === 
    22 
    3 A message by Frederik Eaton to the Haskell mailing list describing this proposal is archived here: [http://www.haskell.org/pipermail/libraries/2005-June/004009.html]. (Note: A proposal by Simon Marlow for "package grafting" predates it: [http://www.haskell.org/pipermail/libraries/2003-August/001310.html]. However, the "package grafting" proposal is different in that it suggests selecting a "mount point" at library installation time, where in the present proposal, the "mount point" is selected each time a module using the library in question is compiled. The difference is important, as one doesn't really want to have to install a new copy of a library just to use it with a different name. Also, Simon Marlow's proposal puts package versions in the module namespace and therefore source code, where we argue for decoupling source code from anything to do with provenance - be it package names or version numbers.) 
     3A message by Frederik Eaton to the Haskell mailing list describing this proposal is archived here: [http://www.haskell.org/pipermail/libraries/2005-June/004009.html]. (Also, see note at the end of this document regarding an earlier proposal by Simon Marlow) 
    44 
    5 This document will go over Frederik's proposal again in brief. The proposal doesn't involve any changes to syntax, only an extra command line option to {{{ghc}}}. 
     5This document will go over Frederik's proposal again in brief. The proposal doesn't involve any changes to syntax, only an extra command line option to {{{ghc}}}, etc., and a small change to Cabal syntax. 
    66 
    7 During compilation of a module, every package would have a "mount point" with respect to which its module namespace would be resolved. Each package should have a default "mount point", but this default would be overridable with an option to {{{ghc}}}. 
     7In this proposal, during compilation of a module, every package would have a "mount point" with respect to which its particular module namespace would be resolved. Each package should have a default "mount point", but this default would be overridable with an option to {{{ghc}}}, etc. 
    88 
    99For example, the {{{X11}}} library currently has module namespace: 
     
    1818}}} 
    1919 
    20 In this proposal, it would have default mount point {{{Graphics.X11}}} and module namespace: 
     20In this proposal, it might instead have default mount point {{{Graphics.X11}}} and module namespace: 
    2121 
    2222{{{ 
     
    2929}}} 
    3030 
    31 If someone wanted to specify a different the mount point, he could use the {{{-package-base}}} option, for example: 
     31To most users of the X11 package, there would be no change - because of the mounting, modules in that package would still appear with the same names in places where the X11 package is used: {{{Graphics.X11.Types}}}, etc. However, if someone wanted to specify a different the mount point, he could use a special compiler option, for instance {{{-package-base}}}: 
    3232 
    3333{{{ 
    3434  ghc -package X11 -package-base Graphics.Unix.X11 ... 
    3535}}} 
     36 
     37(so the imported namespace would appear as {{{Graphics.Unix.X11.Types}}}, {{{Graphics.Unix.X11.Xlib}}}, etc.) 
    3638 
    3739or 
     
    4143}}} 
    4244 
    43 However, usually the default would be used. 
     45(yielding {{{NewX11.Types}}}, {{{NewX11.Xlib}}}, ...; {{{OldX11.Types}}}, {{{OldX11.Xlib}}}, ...) 
     46 
     47However, usually the default mount point would be used. Additionally, Cabal syntax should be extended to support mounting. I would suggest that a mount point appear after a package in the Build-Depends clause of a cabal file: 
     48 
     49{{{ 
     50  Build-Depends: X11(NewX11) 
     51}}} 
     52 
     53And in the package Cabal file, a new clause to specify the default mount point: 
     54 
     55{{{ 
     56  Default-Base: Graphics.X11 
     57}}} 
    4458 
    4559=== Evaluation === 
     
    5367 * ''Simpler module names''. This proposal would allow library authors to use simpler module names in their packages, which would in turn make library code more readable, and more portable between projects. For instance, imagine that I wanted to import some of the code from the {{{X11}}} library into my own project. Currently, I would have to delete every occurrence of {{{Graphics.X11}}} in those modules. Merging future changes after such an extensive modification would become difficult. This is a real problem, which I have encountered while using John Meacham's curses library. There are several different versions of that library being used by different people in different projects, and it is difficult to consolidate them because they all have different module names. The reason they have different module names is that package mounting hasn't been implemented yet. The GhcPackages proposal would not fix the problem. 
    5468 
    55  * ''Development decoupled from naming''. In the present proposal, programmers would be able to start writing a library before deciding on a name for the library. For instance, every module in the {{{Parsec}}} library contains the prefix {{{Text.ParserCombinators.Parsec}}}. This means that either the author of the library had to choose the name {{{Parsec}}} at the very beginning, or he had to make several changes to the text of each module after deciding on the name. Under the present proposal, he would simply call his modules {{{Char}}}, {{{Combinator}}}, {{{Error}}}, etc.; the {{{Text.ParserCombinators}}} prefix would be specified in the build system, for instance in the Cabal file. 
     69 * ''Development decoupled from naming''. (there is a bit of overlap with previous points here) In the present proposal, programmers would be able to start writing a library before deciding on a name for the library. For instance, every module in the {{{Parsec}}} library contains the prefix {{{Text.ParserCombinators.Parsec}}}. This means that either the author of the library had to choose the name {{{Parsec}}} at the very beginning, or he had to make several changes to the text of each module after deciding on the name. Under the present proposal, he would simply call his modules {{{Char}}}, {{{Combinator}}}, {{{Error}}}, etc.; the {{{Text.ParserCombinators}}} prefix would be specified in the build system, for instance in the Cabal file. 
    5670 
    5771Frederik's mailing list message discusses some other minor advantages, but the above points are the important ones. In summary, it is argued that the above proposal should be preferred to GhcPackages because it is both easier to implement (using command line options rather than syntax), and more advantageous for the programmer. 
     72 
     73=== Note on Package Grafting === 
     74 
     75A proposal by Simon Marlow for "package grafting" predates this one: [http://www.haskell.org/pipermail/libraries/2003-August/001310.html]. However, the "package grafting" proposal is different in that it suggests selecting a "mount point" at library installation time, where in the present proposal, the "mount point" is selected each time a module using the library in question is compiled. The difference is important, as one doesn't really want to have to install a new copy of a library just to use it with a different name. Also, Simon Marlow's proposal puts package versions in the module namespace and therefore source code, where we argue for decoupling source code from anything to do with provenance - be it package names or version numbers.