<div class="gmail_extra"><div class="gmail_quote">Thanks for your response.</div><div class="gmail_quote"><br></div><div class="gmail_quote">On Sun, Apr 22, 2012 at 4:45 PM, Brandon Allbery <span dir="ltr"><<a href="mailto:allbery.b@gmail.com" target="_blank">allbery.b@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="im">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></div></blockquote><div><br></div><div>Interesting. Could you elaborate on what the other purposes are, and perhaps point to an instance of the foreign library case?</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></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></div></div></blockquote><div><br></div><div>Oh, I don't intend to replace it -- at most I want to understand why the system is set up the way it is, what the cons/pros are, and so on. I've come across a lot of design discussions for various Haskell features, but not this one; are there any?</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></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.</div>
</div></div></div></blockquote><div><br></div><div>I see. I didn't imagine there was as much variability with respect to module names and implementations as you suggest.</div><div><br></div><div>I'm confused as to how type families vs. fundeps play a role here -- as far as I can tell both are compiler extensions that do not provide modules.</div>
<div><br></div><div>I'm interested to see examples where two or more well-known yet unrelated modules clash under the same name; I can't imagine them coexisting in public very long -- wouldn't the confusion among users (e.g. when looking for documentation) be enough to either reconcile the modules or change one of the names?</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>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></div></div>
</blockquote></div><br></div><div class="gmail_extra">Right, assuming there could only be one implementation of a module, this is one of the main drawbacks; on the flip side, it is a "feature" in that there is no confusion as to what Foo.Bar.Qux means. As it is, any import requires out-of-band information in order to be resolved (both cognitively and by the compiler), in the form of the library it comes from. (There's also versioning information, but that could be equally specified per-library or per-module.)</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">On the other hand, enforcing a single implementation is orthogonal to having a 1-to-1 module/library mapping. That is, you could allow multiple implementations either way.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">Alvaro</div>