Re: Proposal: improve the Data.Tree API

Hi Ivan,

...

then what about the arguably better name `size`? Huh, I thought we already had that.

We do? If there is consensus I would then add `size` with the arguably more efficient implementation: size :: Tree a -> Int size = getSum . F.foldMap (const $ Sum 1)

* An Ord instance (achievable via standalone deriving, though this isn't ideal)

Agreed.

* Functions to take/drop so many levels of the tree (take is relatively easy; drop would result in a Forest).

Similar to treeprune in http://hackage.haskell.org/package/hledger-lib-0.22.1/docs/Hledger-Utils.htm...

mirror :: Tree a -> Tree a mirror (Node a ts) = Node a . reverse $ map mirror ts

I don't have strong feeling about this one, but if more people see as useful, why not... João 2014-02-24 11:38 GMT+00:00 Ivan Lazar Miljenovic :

On 24 February 2014 22:17, Tobias Florek wrote:

...

hi,

...

But to be honest, I don't have strong feelings about this, I'm willing to drop this particular function (length) from the proposal, if there is no consensus.

then what about the arguably better name `size`?

Huh, I thought we already had that.

Some things I missed when I last used Data.Tree:

* An Ord instance (achievable via standalone deriving, though this isn't ideal)

* A function to take the mirror-image of a tree (name not that important):

mirror :: Tree a -> Tree a mirror (Node a ts) = Node a . reverse $ map mirror ts

* Functions to take/drop so many levels of the tree (take is relatively easy; drop would result in a Forest).

...

cheers, tobias florek

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

-- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com http://IvanMiljenovic.wordpress.com _______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries