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)