<div dir="ltr"><br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div>Andrew Coppin wrote:<br>
> Now both packages can be installed at once, but when I say "import<br>
> Data.Hashtable", GHC has no way to know which one I mean. That doesn't sound<br>
> too clever to me...<br>
</div></blockquote><div><br>I agree, Andrew. The hierarchical module approach depends on a global resource for allocating names (or at least everybody agreeing on the scheme of choice). By trying to make all module names equal descriptive categories, it doesn't scale well. There are too many possibilities for overlap or different categorizations for the same thing.<br>
<br>Felipe Lessa wrote:<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div>GHC can hide packages or, put it another way, can show only the<br>
</div>
packages you want. That's what Cabal does when compiling. For example,<br>
try to remove some package from the dependencies and watch GHC<br>
complain.<br>
</blockquote><div><br>That doesn't work if you want to use two packages that have modules sharing the same hierarchical name, and this is a definite possibility given my statements above. Of course, having the ability to import modules from specific packages [1] would fix this, but only as long as the package names are also unique.<br>
<br>Personally, I like the Java package naming scheme recommendation. It scales better, because each package name uses the organization or URI to uniquely identify a subset.<br><br>Sean<br><br>[1] <a href="http://thread.gmane.org/gmane.comp.lang.haskell.cvs.ghc/29319">http://thread.gmane.org/gmane.comp.lang.haskell.cvs.ghc/29319</a> - But notice the not really intended for general use bit.<br>
</div></div></div>