<div dir="auto"><div>Wolfgang, instead of Incremental.Type, instead you could just extend it to something like<div dir="auto"><br></div><div dir="auto">Containers.Map.Incremental,</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">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.</div><br><br><div class="gmail_quote"><div dir="ltr">On Mon, Jul 30, 2018, 7:04 AM Boespflug, Mathieu <<a href="mailto:m@tweag.io">m@tweag.io</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><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" rel="noreferrer">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="m_6006610315076277097h5"><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" rel="noreferrer">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 noreferrer" target="_blank">https://wiki.haskell.org/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/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 noreferrer" target="_blank">github.com/ocramz</a>)<br>
_______________________________________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org" rel="noreferrer noreferrer" target="_blank">Libraries@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer noreferrer noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br>
<br></blockquote></div>
<pre>_______________________________________________
Libraries mailing list
<a href="mailto:Libraries@haskell.org" target="_blank" rel="noreferrer">Libraries@haskell.org</a>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" target="_blank" rel="noreferrer">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a>
</pre></blockquote></div></div></div><br>_______________________________________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org" target="_blank" rel="noreferrer">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-bin/mailman/listinfo/libraries</a><br>
<br></blockquote></div><br></div></div>
_______________________________________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org" target="_blank" rel="noreferrer">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-bin/mailman/listinfo/libraries</a><br>
</blockquote></div></div></div>