Hm, I've been thinking about this this morning as I've gone about my commute. I could indeed imagine a class like the following that had multiple implementations like you're talking about:<div><br><div>class Tree t where</div>
<div> drawTree :: t String -> String<br> flatten :: t a -> [a]</div><div> etc. (see <a href="http://www.haskell.org/ghc/docs/latest/html/libraries/containers/Data-Tree.html">http://www.haskell.org/ghc/docs/latest/html/libraries/containers/Data-Tree.html)</a></div>
<div><br></div><div>I think that for this to be valuable, though, we would need to show that there are functions which can take a generic Tree t and do something useful with it. Still, I suspect there's something there. Maybe I'll take a stab at it this week sometime.</div>
<div><div class="gmail_quote"><br></div><div class="gmail_quote">On Mon, Dec 1, 2008 at 6:24 AM, Andrew Wagner <span dir="ltr"><<a href="mailto:wagner.andrew@gmail.com">wagner.andrew@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">The reasons I've always heard for this is that 1.) It's so easy to define a tree and 2.) There are tons of different variations of trees and what you can do with them. Not that I 100% agree, just what I've always heard. <br>
<div><div></div><div class="Wj3C7c">
<br><div class="gmail_quote">On Mon, Dec 1, 2008 at 6:09 AM, Christian Maeder <span dir="ltr"><<a href="mailto:Christian.Maeder@dfki.de" target="_blank">Christian.Maeder@dfki.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">
Hi,<br>
<br>
I was surprised that I could not find a "classical" binary tree data<br>
structure on hackage, mainly for teaching purposes, like:<br>
<br>
data BinTree a = Nil | Node (BinTree a) a (BinTree a)<br>
<br>
with a couple of utility functions and instances (i.e. in-order traversal).<br>
<br>
Surely, one may argue, that such a tree can always be defined on the fly<br>
when needed, but nobody would argue so for lists or tuples. (Although<br>
I've rarely seen someone redefining lists, it is quite common to<br>
introduce user-defined products or enumerations.)<br>
<br>
There are rose trees in Data.Tree and many other variants of trees are<br>
conceivable, ie.<br>
<br>
data Boom a = Leaf a | Node (Boom a) (Boom a)<br>
<br>
or a kind of combination:<br>
<br>
data BinLeafTree a b =<br>
Leaf b<br>
| Node (BinLeafTree a b) a (BinLeafTree a b)<br>
<br>
I don't know, why I find the above BinTree most important. I'm not even<br>
sure if such a tree could be re-used for Search- or AVL-trees that need<br>
strict fields with redundant size or height counters for efficiency reasons.<br>
<br>
In any case I would find such a data type at least as useful as<br>
<a href="http://hackage.haskell.org/cgi-bin/hackage-scripts/package/OneTuple" target="_blank">http://hackage.haskell.org/cgi-bin/hackage-scripts/package/OneTuple</a><br>
<br>
Who would supply and maintain such a package? Or did I simply not search<br>
hard enough?<br>
<br>
Cheers Christian<br>
<br>
P.S. I took the (non-empty) "Boom" from the Boom-Hierarchy described in<br>
"An Exploration of the Bird-Meertens Formalism" by Roland Backhouse<br>
1988, Groningen<br>
<br>
_______________________________________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org" target="_blank">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>
</blockquote></div><br>
</div></div></blockquote></div><br></div></div>