<div class="gmail_quote">On Fri, Jun 12, 2009 at 2:24 AM, Sven Panne <span dir="ltr"><<a href="mailto:Sven.Panne@aedion.de">Sven.Panne@aedion.de</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;">
<br>
A few final remarks: Leaving out "Graphics." completely would be a very bad<br>
idea, the naming hierarchy should reflect the underlying conceptual hierarchy.<br>
The only problem with hierarchies in general is that sometimes the position in<br>
it is not very clear. <br></blockquote></div><br>Clay Shirky's points in include that this "sometimes" is more like "nearly always", and that the heart of the problem is "the" in "the position" (in a hierarchy). This problem and others discussed at <a href="http://www.shirky.com/writings/ontology_overrated.html" target="_blank">http://www.shirky.com/writings/ontology_overrated.html</a> .<br>
<br><blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;" class="gmail_quote">I have e.g. never fully understood why "Monad" and
"Applicative" are below "Control", but "Foldable" is below "Data"...<br></blockquote><br>Monoid as well. Type classes in general cut across distinctions like Control and Data, so I don't think we'll ever have a comfortable place to put them in the existing hierarchy. If anything, I recommend the top-level name "Class".<br>
<br> - Conal<br><br>