<div dir="ltr"><div class="gmail_extra">On Sun, Apr 22, 2012 at 13:15, Alvaro Gutierrez <span dir="ltr"><<a href="mailto:radical@google.com" target="_blank">radical@google.com</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"><div>As I understand it, a library can provide any number of unrelated modules, and conversely, a single module could be provided by more than one library. I can see how this affords library authors more flexibility, but at a cost: there is no longer a single, unified view of the library universe. (The alternative would be for every module to be its own, hermetic library.) So I'm very interested in the rationale behind that aspect of the library system.</div>
</blockquote><div><br></div><div>One reason: modules serve multiple purposes; one of these is namespacing, and in the case of interfaces to foreign libraries that may force a division that would otherwise not exist.</div>
<div><br></div><div>More generally, making libraries and modules one-to-one means that either modules exist solely for libraries, or libraries must be artificially split. Perhaps this indicates that modules have too many other functions, but in that case you should propose an alternative system to replace them.</div>
<div><br></div><div>As to multiple libraries providing the same module: the Haskell ecosystem is still evolving and it's not always appropriate to give a particular implementation sole ownership of a general module name. Type families vs. functional dependencies are an example of this (theoretically type families were considered superior but to date they haven't lived up to it and recently some cases were shown that fundeps can solve but type families can't; parallel monad libraries based on both still exist). New container implementations have existed as standalone packages, some of which later merge with standard packages while others are discarded. Your proposal to reject this reflects a static library ecosystem that does not exist. (It could be enforced dictatorially, but there is no Guido van Rossum of Haskell and a mistake in an evolving system is difficult to fix after the fact even with a dictator; we're already living with some difficult to fix issues not related to modules.)</div>
<div><br></div></div>-- <br>brandon s allbery <a href="mailto:allbery.b@gmail.com" target="_blank">allbery.b@gmail.com</a><br>wandering unix systems administrator (available) (412) 475-9364 vm/sms<br>
<br>
</div></div>