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
Post by Daniel CartwrightWolfgang, 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.
Post by Boespflug, MathieuI 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.
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
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.
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
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
--
Dave Menendez <***@zednenem.com>
<http://www.eyrie.org/~zednenem/>