... | ... | @@ -26,34 +26,30 @@ A library that does not use the IO monad could communicate that just by not depe |
|
|
|
|
|
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 (G2).
|
|
|
|
|
|
#### (G4) More appropriate string types in IO
|
|
|
#### (G4) Allow well-engineered libraries to be used in what is currently base
|
|
|
|
|
|
|
|
|
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:
|
|
|
At the moment we cannot use libraries like `containers` or `bytestring` in code that is in
|
|
|
the `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:
|
|
|
|
|
|
```wiki
|
|
|
module System.IO where
|
|
|
- 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:
|
|
|
|
|
|
read :: Handle -> Int -> IO ByteString
|
|
|
write :: Handle -> ByteString -> IO ()
|
|
|
```
|
|
|
```wiki
|
|
|
module System.IO where
|
|
|
|
|
|
read :: Handle -> Int -> IO ByteString
|
|
|
write :: Handle -> ByteString -> IO ()
|
|
|
```
|
|
|
|
|
|
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).
|
|
|
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).
|
|
|
|
|
|
- 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:
|
|
|
|
|
|
Splitting base would let us fix this and write a better I/O layer.
|
|
|
- `base-pure` doesn't need `containers`
|
|
|
- `containser` depends on `base-pure`
|
|
|
- `base-io` depends on `containers`
|
|
|
|
|
|
#### (G5) Avoid code copies
|
|
|
|
|
|
|
|
|
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:
|
|
|
|
|
|
- `base-pure` doesn't need `containers`
|
|
|
- `containser` depends on `base-pure`
|
|
|
- `base-io` depends on `containers`
|
|
|
|
|
|
#### (G6) Installable base
|
|
|
#### (G5) Installable base
|
|
|
|
|
|
|
|
|
Right 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.
|
... | ... | @@ -61,7 +57,7 @@ Right now, if a package depends on a specific version of base, there's no way to |
|
|
|
|
|
After the split, hopefully, many subpackages of base will lose their «magic» status and become installable via cabal.
|
|
|
|
|
|
#### (G7) Split base into as FEW packages as possible, consistent with meeting the other goals
|
|
|
#### (G6) Split base into as FEW packages as possible, consistent with meeting the other goals
|
|
|
|
|
|
|
|
|
Other 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.
|
... | ... | @@ -90,7 +86,7 @@ Advantages: |
|
|
Here we genuinely split the code in `base` into sub-packages.
|
|
|
|
|
|
|
|
|
Meets goals (G4), (G5), (G6), I think (G3)
|
|
|
Meets goals (G4), (G5), I think (G3)
|
|
|
|
|
|
|
|
|
Could meet goals (G1), (G2), though shim packages might still be needed.
|
... | ... | |