[Haskell-cafe] Correspondence between libraries and modules

[Alvaro Gutierrez]

Thanks for your response.

On Sun, Apr 22, 2012 at 4:45 PM, Brandon Allbery <allbery.b at gmail.com>wrote:

> 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.
>

Interesting. Could you elaborate on what the other purposes are, and
perhaps point to an instance of the foreign library case?

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.
>

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?

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.
>

I see. I didn't imagine there was as much variability with respect to
module names and implementations as you suggest.

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.

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?



> 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.)
>

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.)

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.

Alvaro
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20120422/0a03ba17/attachment.htm>