Extensions to the module name system in H2020

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

Extensions to the module name system in H2020

Marco Zocca
Hi all,

 I was wondering if there are plans to extend/revisit/tidy up the
module name system
(https://wiki.haskell.org/Hierarchical_module_names) in view of
Haskell 2020.

I'm mostly concerned with scientific/numerical applications, where I
find the current state of things to be a bit chaotic (see
Numeric/Numerical/Optimisation/Optimization etc.).

I would be glad to help out, and gather intelligence from the
community as well via e.g. a poll.

Best,
Marco (github.com/ocramz)
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Extensions to the module name system in H2020

Daniel Cartwright
I am of the opinion that at least most packages should start module names with their package name. Hackage guarantees uniqueness of package names, so this makes sense. The whole Data/Control/Numeric thing seems arbitrary. I would rather see Base.List, Base.Applicative, etc. This has multiple benefits, such as non-overlapping module names by construction (assuming the use of hackage library code), and knowing where the package came from immediately.

On Tue, Jul 24, 2018, 9:06 AM Marco Zocca <[hidden email]> wrote:
Hi all,

 I was wondering if there are plans to extend/revisit/tidy up the
module name system
(https://wiki.haskell.org/Hierarchical_module_names) in view of
Haskell 2020.

I'm mostly concerned with scientific/numerical applications, where I
find the current state of things to be a bit chaotic (see
Numeric/Numerical/Optimisation/Optimization etc.).

I would be glad to help out, and gather intelligence from the
community as well via e.g. a poll.

Best,
Marco (github.com/ocramz)
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Extensions to the module name system in H2020

Wolfgang Jeltsch-3
Hi!

There are also disadvantages in having the module name beginning with the package name.

With that system, extending subtrees of the module tree is made impossible. In the incremental-computing package, for example, we add incrementalization to several common data types. We do this by adding modules like Data.Sequence.Incremental. With your approach, we would have to change that name to something like Incremental.Sequence. However, if someone implements some new data type in a package amazing-type and adds incrementalization support right away, the incremental version would be in AmazingType.Incremental. So the order of the type name and the string Incremental would generally depend on whether a type was implemented before or after the incremental-computing package was created.

In addition, changing the package structure would result in changing the module names. For example, Edward Kmett once split his category theory package into several small packages; under your system, this would result in massive module name changes and consequently compatibility issues.

All in all, I think separating package names from module names is a good idea. The distribution of modules among packages seems more like an implementation detail to me and is a lot dependent on historical accident. It should not pollute module naming.

All the best,
Wolfgang

Am Dienstag, den 24.07.2018, 09:12 -0400 schrieb Daniel Cartwright:
I am of the opinion that at least most packages should start module names with their package name. Hackage guarantees uniqueness of package names, so this makes sense. The whole Data/Control/Numeric thing seems arbitrary. I would rather see Base.List, Base.Applicative, etc. This has multiple benefits, such as non-overlapping module names by construction (assuming the use of hackage library code), and knowing where the package came from immediately.

On Tue, Jul 24, 2018, 9:06 AM Marco Zocca <[hidden email]> wrote:
Hi all,

 I was wondering if there are plans to extend/revisit/tidy up the
module name system
(https://wiki.haskell.org/Hierarchical_module_names) in view of
Haskell 2020.

I'm mostly concerned with scientific/numerical applications, where I
find the current state of things to be a bit chaotic (see
Numeric/Numerical/Optimisation/Optimization etc.).

I would be glad to help out, and gather intelligence from the
community as well via e.g. a poll.

Best,
Marco (github.com/ocramz)
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Extensions to the module name system in H2020

Mathieu Boespflug-3
I agree.

I would add that separating function from provenance is a good thing. It's a good thing that I can import Data.Map if I just want a map type, rather than some bespoke AmazingTypes.Map. It's up to my build tool configuration to bring into scope the right package that provides some implementation of a map. And in a post Backpack world, this will be even more useful, because I can check that whatever implementation I choose matches the the type signatures that my code expects.


On 30 July 2018 at 12:55, Wolfgang Jeltsch <[hidden email]> wrote:
Hi!

There are also disadvantages in having the module name beginning with the package name.

With that system, extending subtrees of the module tree is made impossible. In the incremental-computing package, for example, we add incrementalization to several common data types. We do this by adding modules like Data.Sequence.Incremental. With your approach, we would have to change that name to something like Incremental.Sequence. However, if someone implements some new data type in a package amazing-type and adds incrementalization support right away, the incremental version would be in AmazingType.Incremental. So the order of the type name and the string Incremental would generally depend on whether a type was implemented before or after the incremental-computing package was created.

In addition, changing the package structure would result in changing the module names. For example, Edward Kmett once split his category theory package into several small packages; under your system, this would result in massive module name changes and consequently compatibility issues.

All in all, I think separating package names from module names is a good idea. The distribution of modules among packages seems more like an implementation detail to me and is a lot dependent on historical accident. It should not pollute module naming.

All the best,
Wolfgang

Am Dienstag, den 24.07.2018, 09:12 -0400 schrieb Daniel Cartwright:
I am of the opinion that at least most packages should start module names with their package name. Hackage guarantees uniqueness of package names, so this makes sense. The whole Data/Control/Numeric thing seems arbitrary. I would rather see Base.List, Base.Applicative, etc. This has multiple benefits, such as non-overlapping module names by construction (assuming the use of hackage library code), and knowing where the package came from immediately.

On Tue, Jul 24, 2018, 9:06 AM Marco Zocca <[hidden email]> wrote:
Hi all,

 I was wondering if there are plans to extend/revisit/tidy up the
module name system
(https://wiki.haskell.org/Hierarchical_module_names) in view of
Haskell 2020.

I'm mostly concerned with scientific/numerical applications, where I
find the current state of things to be a bit chaotic (see
Numeric/Numerical/Optimisation/Optimization etc.).

I would be glad to help out, and gather intelligence from the
community as well via e.g. a poll.

Best,
Marco (github.com/ocramz)
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries



_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Extensions to the module name system in H2020

Daniel Cartwright
Wolfgang, instead of Incremental.Type, instead you could just extend it to something like

Containers.Map.Incremental,

but I see your point. At that point, you cannot tell from which package the module came and might even assume at first that it comes from containers.

I also see your point about polluting module names/causing compatibility issues for lots of things. Maybe this is another one of those things that would have been better if adopted earlier on, but is much less practical to adopt at this point or going further.


On Mon, Jul 30, 2018, 7:04 AM Boespflug, Mathieu <[hidden email]> wrote:
I agree.

I would add that separating function from provenance is a good thing. It's a good thing that I can import Data.Map if I just want a map type, rather than some bespoke AmazingTypes.Map. It's up to my build tool configuration to bring into scope the right package that provides some implementation of a map. And in a post Backpack world, this will be even more useful, because I can check that whatever implementation I choose matches the the type signatures that my code expects.


On 30 July 2018 at 12:55, Wolfgang Jeltsch <[hidden email]> wrote:
Hi!

There are also disadvantages in having the module name beginning with the package name.

With that system, extending subtrees of the module tree is made impossible. In the incremental-computing package, for example, we add incrementalization to several common data types. We do this by adding modules like Data.Sequence.Incremental. With your approach, we would have to change that name to something like Incremental.Sequence. However, if someone implements some new data type in a package amazing-type and adds incrementalization support right away, the incremental version would be in AmazingType.Incremental. So the order of the type name and the string Incremental would generally depend on whether a type was implemented before or after the incremental-computing package was created.

In addition, changing the package structure would result in changing the module names. For example, Edward Kmett once split his category theory package into several small packages; under your system, this would result in massive module name changes and consequently compatibility issues.

All in all, I think separating package names from module names is a good idea. The distribution of modules among packages seems more like an implementation detail to me and is a lot dependent on historical accident. It should not pollute module naming.

All the best,
Wolfgang

Am Dienstag, den 24.07.2018, 09:12 -0400 schrieb Daniel Cartwright:
I am of the opinion that at least most packages should start module names with their package name. Hackage guarantees uniqueness of package names, so this makes sense. The whole Data/Control/Numeric thing seems arbitrary. I would rather see Base.List, Base.Applicative, etc. This has multiple benefits, such as non-overlapping module names by construction (assuming the use of hackage library code), and knowing where the package came from immediately.

On Tue, Jul 24, 2018, 9:06 AM Marco Zocca <[hidden email]> wrote:
Hi all,

 I was wondering if there are plans to extend/revisit/tidy up the
module name system
(https://wiki.haskell.org/Hierarchical_module_names) in view of
Haskell 2020.

I'm mostly concerned with scientific/numerical applications, where I
find the current state of things to be a bit chaotic (see
Numeric/Numerical/Optimisation/Optimization etc.).

I would be glad to help out, and gather intelligence from the
community as well via e.g. a poll.

Best,
Marco (github.com/ocramz)
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries


_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Extensions to the module name system in H2020

David Menendez-2
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

Obviously, 1 and 3 are in tension. You can get around 1 with a GHC
extension that lets you import a module from a specific package.

I would argue that 2 is useful when organizing a single package, but
less so when discussing the universe of all publicly available Haskell
libraries. (This is how you end up with stuff like
Text.ParserCombinators.Parsec and Text.PrettyPrint.HughesPJ, where the
package name is effectively at the end of the name.) I don’t see any
particular reason to prefer, say, Data.Sequence.Incremental to
Data.Incremental.Sequence.

Scenario 3 comes up every time this topic is discussed, but I don’t
recall seeing even anecdotal evidence for it. Can anyone name two or
more packages that define modules with the same name(s) such that one
is a drop-in replacement for the other? That isn’t a rhetorical
question. I’d honestly like to know if these exist.

Probably the best solution is to separate the internal name of a
module (used within its package) from the external name (used by
modules in other packages). When including a package, users may assign
a prefix to every module’s name and rename individual modules as
desired. Packages can specify a suggested prefix that will get picked
up by default, unless overridden. This (1) avoids problems from name
collisions, (2) allows hierarchical naming for external modules, and
(3) enables replacing one module with another from another package (or
even the same package).

This sort of scheme has been suggested before (I think Simon Marlow
proposed something like it a few years ago), but it never seemed
pressing enough to do the work. Now that Backpack has taken a big step
towards separating internal and external names, I think this is worth
investigating.


On Mon, Jul 30, 2018 at 10:22 AM, Daniel Cartwright
<[hidden email]> wrote:

> Wolfgang, instead of Incremental.Type, instead you could just extend it to
> something like
>
> Containers.Map.Incremental,
>
> but I see your point. At that point, you cannot tell from which package the
> module came and might even assume at first that it comes from containers.
>
> I also see your point about polluting module names/causing compatibility
> issues for lots of things. Maybe this is another one of those things that
> would have been better if adopted earlier on, but is much less practical to
> adopt at this point or going further.
>
>
> On Mon, Jul 30, 2018, 7:04 AM Boespflug, Mathieu <[hidden email]> wrote:
>>
>> I agree.
>>
>> I would add that separating function from provenance is a good thing. It's
>> a good thing that I can import Data.Map if I just want a map type, rather
>> than some bespoke AmazingTypes.Map. It's up to my build tool configuration
>> to bring into scope the right package that provides some implementation of a
>> map. And in a post Backpack world, this will be even more useful, because I
>> can check that whatever implementation I choose matches the the type
>> signatures that my code expects.
>>
>>
>> On 30 July 2018 at 12:55, Wolfgang Jeltsch <[hidden email]>
>> wrote:
>>>
>>> Hi!
>>>
>>> There are also disadvantages in having the module name beginning with the
>>> package name.
>>>
>>> With that system, extending subtrees of the module tree is made
>>> impossible. In the incremental-computing package, for example, we add
>>> incrementalization to several common data types. We do this by adding
>>> modules like Data.Sequence.Incremental. With your approach, we would have to
>>> change that name to something like Incremental.Sequence. However, if someone
>>> implements some new data type in a package amazing-type and adds
>>> incrementalization support right away, the incremental version would be in
>>> AmazingType.Incremental. So the order of the type name and the string
>>> Incremental would generally depend on whether a type was implemented before
>>> or after the incremental-computing package was created.
>>>
>>> In addition, changing the package structure would result in changing the
>>> module names. For example, Edward Kmett once split his category theory
>>> package into several small packages; under your system, this would result in
>>> massive module name changes and consequently compatibility issues.
>>>
>>> All in all, I think separating package names from module names is a good
>>> idea. The distribution of modules among packages seems more like an
>>> implementation detail to me and is a lot dependent on historical accident.
>>> It should not pollute module naming.
>>>
>>> All the best,
>>> Wolfgang
>>>
>>> Am Dienstag, den 24.07.2018, 09:12 -0400 schrieb Daniel Cartwright:
>>>
>>> I am of the opinion that at least most packages should start module names
>>> with their package name. Hackage guarantees uniqueness of package names, so
>>> this makes sense. The whole Data/Control/Numeric thing seems arbitrary. I
>>> would rather see Base.List, Base.Applicative, etc. This has multiple
>>> benefits, such as non-overlapping module names by construction (assuming the
>>> use of hackage library code), and knowing where the package came from
>>> immediately.
>>>
>>> On Tue, Jul 24, 2018, 9:06 AM Marco Zocca <[hidden email]> wrote:
>>>
>>> Hi all,
>>>
>>>  I was wondering if there are plans to extend/revisit/tidy up the
>>> module name system
>>> (https://wiki.haskell.org/Hierarchical_module_names) in view of
>>> Haskell 2020.
>>>
>>> I'm mostly concerned with scientific/numerical applications, where I
>>> find the current state of things to be a bit chaotic (see
>>> Numeric/Numerical/Optimisation/Optimization etc.).
>>>
>>> I would be glad to help out, and gather intelligence from the
>>> community as well via e.g. a poll.
>>>
>>> Best,
>>> Marco (github.com/ocramz)
>>> _______________________________________________
>>> Libraries mailing list
>>> [hidden email]
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>>
>>> _______________________________________________
>>> Libraries mailing list
>>> [hidden email]
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>>
>>>
>>> _______________________________________________
>>> Libraries mailing list
>>> [hidden email]
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>>
>>
>> _______________________________________________
>> Libraries mailing list
>> [hidden email]
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
>
> _______________________________________________
> Libraries mailing list
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>



--
Dave Menendez <[hidden email]>
<http://www.eyrie.org/~zednenem/>
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Extensions to the module name system in H2020

Henning Thielemann

On Mon, 30 Jul 2018, David Menendez wrote:

> Scenario 3 comes up every time this topic is discussed, but I don’t
> recall seeing even anecdotal evidence for it. Can anyone name two or
> more packages that define modules with the same name(s) such that one
> is a drop-in replacement for the other? That isn’t a rhetorical
> question. I’d honestly like to know if these exist.

stream-fusion provided a drop-in replacement for Data.List with improved
list fusion.

My prelude2010 provides a drop-in replacement for Prelude, however the
user actually wants to stick to prelude2010 in order to get the old
Prelude signatures back.
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Extensions to the module name system in H2020

Wolfgang Jeltsch-3
In reply to this post by David Menendez-2
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.

All the best,
Wolfgang
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Extensions to the module name system in H2020

Daniel Cartwright
"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."

Not sure I agree that that is necessarily the case.

Transformers.ExceptT
Transformers.ReaderT
These.ChronicleT

This lets me know exactly where these transformers came from, just by reading the module name.


On Tue, Jul 31, 2018, 8:44 AM Wolfgang Jeltsch <[hidden email]> 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.

All the best,
Wolfgang
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Extensions to the module name system in H2020

Wolfgang Jeltsch-3
Am Dienstag, den 31.07.2018, 08:51 -0400 schrieb Daniel Cartwright:
"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."

Not sure I agree that that is necessarily the case.

Transformers.ExceptT
Transformers.ReaderT
These.ChronicleT

This lets me know exactly where these transformers came from, just by reading the module name.

But I don’t want to see where those transformers “came from” but that they are certain monad transformers. The latter is expressed by the consistent naming Control.Monad.Trans.⟨type-of-transformer⟩.

All the best,
Wolfgang

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Extensions to the module name system in H2020

Daniel Cartwright
As someone who reads documentation, I do want to see where they came from. The source (not code, but origin) of a module is not an implementation detail, it's a place for documentation. This naming scheme is also consistent in its own right.

On Tue, Jul 31, 2018, 9:29 AM Wolfgang Jeltsch <[hidden email]> wrote:
Am Dienstag, den 31.07.2018, 08:51 -0400 schrieb Daniel Cartwright:
"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."

Not sure I agree that that is necessarily the case.

Transformers.ExceptT
Transformers.ReaderT
These.ChronicleT

This lets me know exactly where these transformers came from, just by reading the module name.

But I don’t want to see where those transformers “came from” but that they are certain monad transformers. The latter is expressed by the consistent naming Control.Monad.Trans.⟨type-of-transformer⟩.

All the best,
Wolfgang
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Extensions to the module name system in H2020

David Menendez-2
In reply to this post by Wolfgang Jeltsch-3
On Tue, Jul 31, 2018 at 8:43 AM, Wolfgang Jeltsch
<[hidden email]> 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 <[hidden email]>
<http://www.eyrie.org/~zednenem/>
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Extensions to the module name system in H2020

Wolfgang Jeltsch-3
Am Dienstag, den 31.07.2018, 14:57 -0400 schrieb David Menendez:
> 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?

I’ve never considered the module names of Parsec, QuickCheck, etc.
mentioning the packages the modules come from but mentioning the
interfaces the modules provide. So for me “QuickCheck” doesn’t refer to
the QuickCheck package but to a certain way of doing tests with a
certain interface.

All the best,
Wolfgang
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries