Changes between Version 23 and Version 24 of SplitBase


Ignore:
Timestamp:
Mar 13, 2013 8:06:08 AM (2 years ago)
Author:
simonpj
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • SplitBase

    v23 v24  
    2121A 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 ==== (G4) More appropriate string types in IO ====
     23==== (G4) Allow well-engineered libraries to be used in what is currently base ====
    2424
    25 We would like to be able to use the Text and !ByteString types in the I/O layer. For example, we'd like to have:
     25At the moment we cannot use libraries like `containers` or `bytestring` in code that is in
     26the `base` package.  (Why?  Because those libraries in turn depend on `base` and we don't allow mutual recursion between packages.)  If we split `base` up, we could use these libraries, and perhaps others, in at least parts of what is currently `base`.   Two examples:
    2627
     28 * We would like to be able to use the Text and !ByteString types in the I/O layer. For example, we'd like to have:
    2729{{{
    2830module System.IO where
     
    3133write :: Handle -> ByteString -> IO ()
    3234}}}
     35 but since `System.IO` is defined in base it cannot depend on e.g. bytestring and thus we cannot write these functions. At the moment we have to use `String` for all I/O which is both slow, due to its cache-inefficient nature, and incorrect, as `String` is not a representation of a sequence of bytes (but rather a sequence of Unicode code points).
    3336
    34 but since `System.IO` is defined in base it cannot depend on e.g. bytestring and thus we cannot write these functions. At the moment we have to use `String` for all I/O which is both slow, due to its cache-inefficient nature, and incorrect, as `String` is not a representation of a sequence of bytes (but rather a sequence of Unicode code points).
     37 * 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:
     38   * `base-pure` doesn't need `containers`
     39   * `containser` depends on `base-pure`
     40   * `base-io` depends on `containers`
    3541
    36 Splitting base would let us fix this and write a better I/O layer.
    37 
    38 ==== (G5) Avoid code copies ====
    39 
    40 Johan 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:
    41  * `base-pure` doesn't need `containers`
    42  * `containser` depends on `base-pure`
    43  * `base-io` depends on `containers`
    44 
    45 ==== (G6) Installable base ====
     42==== (G5) Installable base ====
    4643
    4744Right 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.
     
    4946After the split, hopefully, many subpackages of base will lose their «magic» status and become installable via cabal.
    5047
    51 ==== (G7) Split base into as FEW packages as possible, consistent with meeting the other goals ====
     48==== (G6) Split base into as FEW packages as possible, consistent with meeting the other goals ====
    5249
    5350Other 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.
     
    7370Here we genuinely split the code in `base` into sub-packages.
    7471
    75 Meets goals (G4), (G5), (G6), I think (G3)
     72Meets goals (G4), (G5), I think (G3)
    7673
    7774Could meet goals (G1), (G2), though shim packages might still be needed.