<div dir="ltr">I agree.<div><br></div><div>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.</div><div><br></div><div class="gmail_extra">
<br><div class="gmail_quote">On 30 July 2018 at 12:55, Wolfgang Jeltsch <span dir="ltr"><<a href="mailto:wolfgang-it@jeltsch.info" target="_blank">wolfgang-it@jeltsch.info</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div>Hi!</div><div><br></div><div>There are also disadvantages in having the module name beginning with the package name.</div><div><br></div><div>With that system, extending subtrees of the module tree is made impossible. In the <i>incremental-computing</i> package, for example, we add incrementalization to several common data types. We do this by adding modules like <i>Data.Sequence.Incremental</i>. With your approach, we would have to change that name to something like <i>Incremental.Sequence</i>. However, if someone implements some new data type in a package <i>amazing-type</i> and adds incrementalization support right away, the incremental version would be in <i>AmazingType.Incremental</i>. So the order of the type name and the string <i>Incremental</i> would generally depend on whether a type was implemented before or after the <i>incremental-computing</i> package was created.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>All the best,</div><div>Wolfgang</div><div><div class="h5"><div><br></div><div>Am Dienstag, den 24.07.2018, 09:12 -0400 schrieb Daniel Cartwright:</div><blockquote type="cite"><div dir="auto">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.</div><br><div class="gmail_quote"><div dir="ltr">On Tue, Jul 24, 2018, 9:06 AM Marco Zocca <<a href="mailto:zocca.marco@gmail.com" target="_blank">zocca.marco@gmail.com</a>> wrote:<br></div><blockquote type="cite">Hi all,<br>
<br>
 I was wondering if there are plans to extend/revisit/tidy up the<br>
module name system<br>
(<a href="https://wiki.haskell.org/Hierarchical_module_names" rel="noreferrer noreferrer" target="_blank">https://wiki.haskell.org/<wbr>Hierarchical_module_names</a>) in view of<br>
Haskell 2020.<br>
<br>
I'm mostly concerned with scientific/numerical applications, where I<br>
find the current state of things to be a bit chaotic (see<br>
Numeric/Numerical/<wbr>Optimisation/Optimization etc.).<br>
<br>
I would be glad to help out, and gather intelligence from the<br>
community as well via e.g. a poll.<br>
<br>
Best,<br>
Marco (<a href="http://github.com/ocramz" rel="noreferrer noreferrer" target="_blank">github.com/ocramz</a>)<br>
______________________________<wbr>_________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org" rel="noreferrer" target="_blank">Libraries@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer noreferrer" target="_blank">http://mail.haskell.org/cgi-<wbr>bin/mailman/listinfo/libraries</a><br>
<br></blockquote></div>
<pre>______________________________<wbr>_________________
Libraries mailing list
<a href="mailto:Libraries@haskell.org" target="_blank">Libraries@haskell.org</a>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" target="_blank">http://mail.haskell.org/cgi-<wbr>bin/mailman/listinfo/libraries</a>
</pre></blockquote></div></div></div><br>______________________________<wbr>_________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org">Libraries@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-<wbr>bin/mailman/listinfo/libraries</a><br>
<br></blockquote></div><br></div></div>