Changes between Version 21 and Version 22 of SplitBase


Ignore:
Timestamp:
Mar 11, 2013 11:39:56 PM (2 years ago)
Author:
simonpj
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • SplitBase

    v21 v22  
    99Structural changes to the base package can be attempted towards the following goals: 
    1010 
    11 ==== To allow changes to internals without forcing a version-bump on ‘base’, on which every package depends ==== 
     11==== (G1) To allow changes to internals without forcing a version-bump on ‘base’, on which every package depends ==== 
    1212 
    1313SPJ: But that goal needs a bit of unpacking. Suppose we divided base into six, base1, base2, base3, etc, but each was a vertical silo and every other package depended on all six.  Then nothing would be gained; bumping any of them would cause a ripple of bumps down the line. 
    1414 
    15 ==== To allow packages to be explictly about what they need ==== 
     15==== (G2) To allow packages to be explict about what they need ==== 
    1616 
    1717A library that does not use the IO monad could communicate that just by not depending on some base-io package. Similar with the Foreign Function Interface or unsafe operations. 
    1818 
    19 ==== To allow alternative implementations/targets ==== 
     19==== (G3) To allow alternative implementations/targets ==== 
    2020 
    21 A Haskell-to-Javascript compiler will not support File IO, or maybe not even IO at all. It would be desirable such an implementation has a chance to at least provide a complete and API compatible base-pure package, and that one can hence reasonably assume that packages and libraries depending only on `base-pure` will indeed work without modification. This might be subsumed by fulfilling the previous goal. 
     21A Haskell-to-Javascript compiler will not support File IO, or maybe not even IO at all. It would be desirable such an implementation has a chance to at least provide a complete and API compatible base-pure package, and that one can hence reasonably assume that packages and libraries depending only on `base-pure` will indeed work without modification. This might be subsumed by fulfilling (G2). 
    2222 
    23 ==== More appropriate string types in IO ==== 
     23==== (G4) More appropriate string types in IO ==== 
    2424 
    2525Johan would like to have text Handles use the Text type and binary Handles use the !ByteString type. Right now we have this somewhat awkward setup where the I/O APIs are spread out and bundled with pure types. Splitting base would let us fix this and write a better I/O layer. 
    2626 
    27 ==== Avoid code copies ==== 
     27'''SPJ''': I don't understand either the problem or the solution. 
    2828 
    29 Johan says: The I/O manager currently has a copy of !IntMap inside its implementation because base cannot use containers. Splitting base would let us get rid of this code duplication.  
     29==== (G5) Avoid code copies ==== 
    3030 
    31 ==== Installable base ==== 
     31Johan says: The I/O manager currently has a copy of !IntMap inside its implementation because base cannot use containers. Why?  Becuase `containers` depends on `base`, so `base` can't depend on `containers`.  Splitting base would let us get rid of this code duplication. For example: 
     32 * `base-pure` doesn't need `containers` 
     33 * `containser` depends on `base-pure` 
     34 * `base-io` depends on `containers` 
     35 
     36==== (G6) Installable base ==== 
     37 
    3238Right now, if a package depends on a specific version of base, there's no way to compile it with GHC that provides a different version of base. 
    3339 
    3440After the split, hopefully, many subpackages of base will lose their «magic» status and become installable via cabal. 
    3541 
    36 ==== Split base into as FEW packages as possible, consistent with meeting the other goals ==== 
     42==== (G7) Split base into as FEW packages as possible, consistent with meeting the other goals ==== 
    3743 
    38 In contrast to the non-goal of splitting base as much as possible. Johan points out, a split now could paint us into a corner later, so we should not gratuitously split things up. 
     44Other things being equal, we should split `base` into as few packages as necessary to meet other goals. Johan points out, a split now could paint us into a corner later, so we should not gratuitously split things up. 
    3945 
    4046 
     
    4349==== Large base, re-exporting API packages ==== 
    4450 
     51Here we would keep one large `base` package, as now, with a number of wrapper packages that selectively expose stable sub-APIs. 
     52 
     53Meets goals (G1), (G2), (G3) 
     54 
    4555Advantages: 
    4656 
    47  * No to little changes to the actual code in base 
     57 * Cheap: little or no changes to the actual code in base 
    4858 * Easier to define the APIs as desired, i.e. focused and stable, without worrying about implementation-imposed cycles 
    4959 * No need to include internal modules in the API packages 
     
    5262==== Actual base split ==== 
    5363 
     64Here we genuinely split the code in `base` into sub-packages. 
     65 
     66Meets goals (G4), (G5), (G6), I think (G3)  
     67 
     68Could meet goals (G1), (G2), though shim packages might still be needed. 
     69 
    5470Advantages: 
    5571 
    56  * Forces disentanglement of the implementation (i.e. `IOError`-less `error`) 
     72 * Quite a bit of work 
     73 * Narrows implementation choices, because packages can't be mutually recursive. (i.e. forces `IOError`-less `error`) 
    5774 * Hence further development may be easier ([http://www.haskell.org/pipermail/glasgow-haskell-users/2013-February/023818.html according to Ian]) 
    5875 * Some base-foo package can use other libraries like containers in their implementation (!IntMap issue)