Changes between Version 19 and Version 20 of SplitBase


Ignore:
Timestamp:
Mar 7, 2013 8:15:56 PM (16 months 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