On Thu, Feb 14, 2013 at 6:48 AM, Joachim Breitner <span dir="ltr"><<a href="mailto:mail@joachim-breitner.de" target="_blank">mail@joachim-breitner.de</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Maybe the proper is to reverse the whole approach: Leave base as it is,<br>
and then build re-exporting smaller packages (e.g. a base-pure) on top<br>
of it. The advantage is:<br>
* No need to rewrite the tightly intertwined base.<br>
* Libraries still have the option to have tighter dependencies.<br>
* Base can evolve with lots of breaking changes, as long as they<br>
do not affect the API by the smaller packages.<br>
* Development of this collection can happen outside the GHC tree.<br>
* Alternative implementations for (some of) these packages can be<br>
created, if the reason why they could not be moved out of base<br>
is one of implementation, not of API<br>
<br>
How does that sound?</blockquote><div><br></div><div>I'm not in favor of this approach as it precludes pushing any data types down the stack. In particular, we want text and bytestring to be below the I/O layer, so we can defined Handles that work with those in base itself.</div>
<div><br></div></div>