Why aren't modules prefixed their package name?

Learn
1

This follows from discussion on the Functional Programming Discord.

In Java, Python and various other languages, modules are always prefixed with their package name. For example: import org.springframework. ... from Java or import pandas from Python.

Why do Haskell packages not do this? Is it a cultural thing?

For some additional context, we where discussing this transitive package dependencies. If package A, depends on B and B depends on C, should A be allowed to import C’s modules without directly depending on C. I’m inclined to say yes because B’s types may not make sense without C’s types.

These transitive dependencies would cause problems if module names where not prefixed with their package name. In Java and Python, because nearly all modules are prefixed. They don’t run into this problem. I am not familiar with their language package managers to say if their dependencies are transitive, but they certainly have the option to make them so. Their language runtimes don’t allow overlapping packages names.

In Hazy, I plan making packages have transitive dependencies and I currently expect full qualified module names to be unique. I am aware that GHC allows packages to have overlapping module names but I am hesitant to allow this.

2

In that case, I think module B should reexport the modules of package C, allowing for A to not depend on C. Also, many packages do use the name of their project/something related as a root. e.g. Dataframe,units,dimensional.

These transitive dependencies would cause problems if module names where not prefixed with their package name.

What problems?

3

If that is the case, I expect library B to re-export what is needed from C, although it has its drawbacks.

4

The problem is that there would be incompatible sets of packages. If package A and B both export module X. Then you can’t depend on both A and B because import X would be ambiguous.

With my current plan for Hazy, not only would you not be able to depend on both A and B, but it would disallow A and B from appearing in the same program at all. As I expect module names to be unique.

5

This kind of breakage, for example:

6

Ok, but if they were already prefixed by package name, the ram wouldn’t be a drop in replacement for memory. ram is intended for someone to just replace memory with ram in their cabal file. I don’t think there’s any good way to get around this problem.

7

ram was not a drop-in replacement for memory, it turns out. Better if this were discovered earlier, I think.

8

Haskell currently allows you to use package-qualified imports by using the PackageImports extension. The documentation for this extension notes that “You probably don’t need to use this feature” and that “It can lead to fragile dependencies in the common case: modules occasionally move from one package to another, rendering any package-qualified imports broken”

9

Making unprefixed module names the default has allowed for much smoother migrations when modules enter or leave major libraries. Off the top of my head, I can think of package semigroups, which incubated Data.Semigroup and Data.List.NonEmpty before they entered base, and package attoparsec-aeson, which holds aeson’s old attoparsec-based parse.

I think it’s a useful feature, and if you plan to strictly qualify your identifiers including by package name, you might need to think about how to get similar effects in your module system.

I’m a bit surprised by the amount of people who seem to be in favour of “if A depends on B depends on C, then A should be able to import from C” as a general principle. C could be an implementation detail of B, in which case A should have no right to import from C unless it also depends on it directly.