... | @@ -26,6 +26,16 @@ A library that does not use the IO monad could communicate that just by not depe |
... | @@ -26,6 +26,16 @@ 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 the previous goal.
|
|
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.
|
|
|
|
|
|
|
|
#### More appropriate string types in IO
|
|
|
|
|
|
|
|
|
|
|
|
Johan 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.
|
|
|
|
|
|
|
|
##### Avoid code copies ====
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
#### Split base into as FEW packages as possible, consistent with meeting the other goals
|
|
#### Split base into as FEW packages as possible, consistent with meeting the other goals
|
|
|
|
|
|
|
|
|
... | | ... | |