Changes between Version 19 and Version 20 of SplitBase


Ignore:
Timestamp:
Mar 7, 2013 8:15:56 PM (2 years ago)
Author:
nomeata
Comment:

Compare approaches

Legend:

Unmodified
Added
Removed
Modified
  • SplitBase

    v19 v20  
    33In a [http://www.haskell.org/pipermail/glasgow-haskell-users/2013-February/023764.html thread on glasglow-haskell-users] in February some ideas about splitting base in smaller components were floating around. This wiki page tries to assemble ideas on how to re-group the modules.
    44
    5 This has been discussed before, e.g. in [2008 http://www.haskell.org/pipermail/libraries/2008-August/010543.html].
     5This has been discussed before, e.g. in [http://www.haskell.org/pipermail/libraries/2008-August/010543.html 2008].
    66
    77=== Goals ===
     
    3939
    4040
     41=== Approaches ===
     42
     43==== Large base, re-exporting API packages ====
     44
     45Advantages:
     46
     47 * No to little changes to the actual code in base
     48 * Easier to define the APIs as desired, i.e. focused and stable, without worrying about implementation-imposed cycles
     49 * No need to include internal modules in the API packages
     50 * Alternative compilers/targets can provide these APIs with totally independent implementations
     51
     52==== Actual base split ====
     53
     54Advantages:
     55
     56 * Forces disentanglement of the implementation (i.e. `IOError`-less `error`)
     57 * Hence further development may be easier ([http://www.haskell.org/pipermail/glasgow-haskell-users/2013-February/023818.html according to Ian])
     58 * Some base-foo package can use other libraries like containers (IntMap issue)
     59 * Alternative compilers/targets may only have to reimplement some of the base-* packages.
     60 * Possibly fewer modules in “magic” packages that cannot be installed via cabal.
     61
    4162=== Non-Obvious interdependencies ===
    4263