Extensions to the module name system in H2020

[David Menendez]

On Tue, Jul 31, 2018 at 8:43 AM, Wolfgang Jeltsch
<wolfgang-it at 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 at zednenem.com>
<http://www.eyrie.org/~zednenem/>