On Tue, Jul 31, 2018 at 8:43 AM, Wolfgang Jeltsch <wolfgang-it@jeltsch.info> wrote:
Am Montag, den 30.07.2018, 15:03 -0400 schrieb David Menendez:
I think there are several ideas being discussed here, and it may be helpful to distinguish them.
1. Two packages may unintentionally include modules with the same name, making it difficult to use both at once 2. Module names should be organized in some logical manner 3. A package may want to import a module without tying it to a specific package
There is also the situation where the package name isn’t essential and shouldn’t get in the way when naming modules. For example, there are a lot of monad transformers in the world. The `transformers` package implements some of them; others are added by other packages. It is good if the module that implements a certain kind of monad transformer has a name of the form `Control.Monad.Trans.⟨type-of-transformer⟩`. Having the package name in the module name would be like revealing an implementation detail.
How would the package name get in the way? What is it getting in the way of? Having related modules have similar prefixes may be useful from an organizational standpoint, but it has no impact at all on how they are used. This isn’t Java, where I can import Control.Monad.* and bring all the submodules in scope. I agree with the argument that reflecting the provenance of a module in its name is not always desirable, but the idea that it is never desirable is obviously incorrect. Are Parsec, QuickCheck, and pretty all doing it wrong? Again, this is only an issue because we don’t have a convenient way of renaming modules when we declare a dependency on a package. With a small addition to the infrastructure, we can avoid this argument entirely. -- Dave Menendez <dave@zednenem.com> <http://www.eyrie.org/~zednenem/>