Extensions to the module name system in H2020

[Boespflug, Mathieu]

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 <wolfgang-it at jeltsch.info> 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 <zocca.marco at gmail.com> 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
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
> _______________________________________________
> Libraries mailing listLibraries at haskell.orghttp://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20180730/40887a83/attachment.html>