On Fri, Feb 22, 2013 at 3:34 PM, Joachim Breitner <span dir="ltr">&lt;<a href="mailto:mail@joachim-breitner.de" target="_blank">mail@joachim-breitner.de</a>&gt;</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">

right, there is a tension between having just independent APIs and<br>
having also independent implementations. My main goal is to allow<br>
packages to specify their imports more precisely, to require less<br>
changes as not-so-common stuff in base evolves and to make it easier for<br>
alternative compiler/targets to implement parts of base; this would just<br>
require providing better grouped APIs.<br>
<br>
But if we want that while retaining the freedom to have an entangled<br>
implementation, we are back at the &quot;large base + specific re-exporting<br>
packages&quot; approach, which wasn’t particularly well received here.<br></blockquote><div><br></div><div>I don&#39;t know about entangled implementations. But I&#39;d like to have a base package (e.g. your base-pure) that has a consistent set of basic data types e.g. Int, Word, Float, Double, Char, String, ByteString, Text, [a], Maybe, Either, and so forth. These are logically at the same layer. I think splitting them according to how they happen to be implemented at the moment is a misstake. It would give us a illogical and unstable layering in the long run.</div>

</div>