Amen to Iavor's proposal!<br><br>Hierarchical decomposition leads to arbitrary and thus unguessable decisions, because many such decompositions are possible. This problem nearly always happens, as Clay Shirky illustrates at <a href="http://www.shirky.com/writings/ontology_overrated.html">http://www.shirky.com/writings/ontology_overrated.html</a> . Iavor has given some examples. Data vs Control provides some more. Another, as Wolfgang hinted at, is UI vs Graphics. These two notions overlap, with neither being more specific than the other.<br>
<br>Module hierarchy tries to give ontology and collision-avoidance. Ontology is an failure as we've seen (and inevitably so, as Clay Shirky demonstrates). Collision-avoidance has failed also, as Iavor pointed out, since packages can easily have module name collisions (e.g., I had a Data.Fun at one point). However, we already prohibit collisions of package names, so we can get module uniqueness by using the package name as the top-level portion of every module in a package. Beyond that requirement, package implementors can use whatever organzation style they like.<br>
<br> - Conal<br><br><div class="gmail_quote">On Fri, Jun 19, 2009 at 12:08 AM, Iavor Diatchki <span dir="ltr"><<a href="mailto:iavor.diatchki@gmail.com">iavor.diatchki@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hi,<br>
I agree with Johan that the name hierarchy should be changed. The<br>
current approach has a number of drawbacks. In no specific order:<br>
<br>
* Trying to use a single hierarchy to classify modules is inaccurate<br>
because many module could logically belong in multiple locations. We<br>
have many examples that demonstrate this in the current hierarchy:<br>
Text is not Data; the HTTP protocol is under Network, but XML is under<br>
Text even though both are text based protocols; URLs are under Network<br>
(and so are neither Data nor Text), file operations are under<br>
System.IO but Network operations are in their own name space. This is<br>
not because the authors of the packages were not careful in selecting<br>
the names. The problem is that for many module there isn't a single<br>
name that describes its content.<br>
<br>
* The current naming convention makes it harder to understand<br>
programs (independent of overly long import names like<br>
Network.Protocol.Http.Cookies, which could be just as well described<br>
as Protocol.Network.Http.Cookies). The real problem with readability<br>
is that looking at the imports of a module does not give any<br>
indication of what package the modules come from, which makes it hard<br>
to understand the dependencies of the module and, more pragmatically,<br>
makes it hard to lookup documentation for the module contents.<br>
<br>
* The current naming convention does not scale because each package<br>
may introduce modules that are placed all over the name hierarchy.<br>
For example, the utf-8 library redefines some IO operations so it has<br>
modules under System.IO, it provides some ByteString support so it<br>
also has modules under Data.ByteString, and finally it also deals with<br>
text, so it has modules under Text.Codec. This is a problem because<br>
it is hard for package writers to avoid name collisions, without<br>
knowing the modules in all available packages.<br>
<br>
I think that a better way to organize our programs is to prefix the<br>
modules in a package with the package name. This will avoid the name<br>
collision issue (or at least, greatly simplify it, because packages<br>
that are uploaded to hackage need to have different names). It would<br>
also make the dependencies of a module quite obvious. It would also<br>
make our import lists much simpler. For example, we would write<br>
"import HaXml" instead of import "Text.XML.HaXML", or "import<br>
Parsec.Char" instead of "import Text.ParsingCombinators.Parsec.Char".<br>
If classifying modules according to their purpose is necessary (and I<br>
am not sure that it is, if we can do it at the package level), then we<br>
could think of a more suitable mechanism to achieve that goal then the<br>
hierarchical names.<br>
<font color="#888888"><br>
-Iavor<br>
</font><div><div></div><div class="h5"><br>
On Tue, Jun 16, 2009 at 7:45 AM, Ian Lynagh<<a href="mailto:igloo@earth.li">igloo@earth.li</a>> wrote:<br>
> On Fri, Jun 12, 2009 at 10:46:07PM +0200, Johan Tibell wrote:<br>
>><br>
>> Perhaps it's time to overhaul the hierarchy. Some top level module<br>
>> namespaces like Network have become very crowded. Network is a very generic<br>
>> name that it conveys very little information today when most software has a<br>
>> network component. I suggest that parts of it be broken out into new top<br>
>> level modules. As a first step I suggest we create a new Http (and not HTTP<br>
>> with all caps please) module where we can have:<br>
>><br>
>> Http.Client<br>
>> Http.Server<br>
>> Http.UrlEncoding<br>
>> Http.Cookies<br>
>> etc.<br>
><br>
> I don't follow the logic. If Network is crowded, doesn't that mean we<br>
> should be aiming to subdivide it, e.g. moving<br>
> Network.Http.*<br>
> to<br>
> Network.Protocol.Http.*<br>
> (FSVO "Protocol"; could be "Tcp", or something else entirely)?<br>
><br>
> If we move everything up to the root then the root will be even more<br>
> crowded than Network is.<br>
><br>
><br>
> Thanks<br>
> Ian<br>
><br>
> _______________________________________________<br>
> Libraries mailing list<br>
> <a href="mailto:Libraries@haskell.org">Libraries@haskell.org</a><br>
> <a href="http://www.haskell.org/mailman/listinfo/libraries" target="_blank">http://www.haskell.org/mailman/listinfo/libraries</a><br>
><br>
_______________________________________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org">Libraries@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/libraries" target="_blank">http://www.haskell.org/mailman/listinfo/libraries</a><br>
</div></div></blockquote></div><br>