Changes between Version 23 and Version 24 of SplitBase


Ignore:
Timestamp:
Mar 13, 2013 8:06:08 AM (13 months 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.