Data.Tree additional functions

[jcristovao]

Hi,
The provided tree api seems a little small. After doing the usual workflow of defining my own version of, for example, subtreeat :: Eq a => a -> Tree a -> Maybe (Tree a), only to later find it defined somewhere at hackage, my question is:

Does it make sense to include some of the functions defined in:
http://hackage.haskell.org/package/debian-3.81/docs/Debian-Apt-Dependencies.html#g:3
and
http://hackage.haskell.org/package/hledger-lib-0.22.1/docs/Hledger-Utils.html#v:subtreeat
As functions of Data.Tree, or should that be left for a separate package?

My imediate suggestions would be:
treefilter :: (a -> Bool) -> Tree a -> Tree a
subtreeat :: Eq a => a -> Tree a -> Maybe (Tree a)
subtreeinforest :: Eq a => a -> [Tree a] -> Maybe (Tree a)

Or am I missing some easier way of avoiding these functions?

[foxik]

The Tree API is really very poor. The reason is only that nobody has spend time working on it.

It makes sense to add functions to the Treemodule. The naming should be consistent with the rest of the containers API, so treefilter should really be just filter, the subtreeat maybe lookupTree, etc.

Please note that containers API changes are subject to http://www.haskell.org/haskellwiki/Library_submissions process, especially see http://www.haskell.org/haskellwiki/Library_submissions#Guidance_for_proposers. If you want to pursue this, please send a specific proposal (functions and their types you want to add; no implementation is needed at this point) to the libraries mailing list.

Cheers,
Milan

[jcristovao]

Allright, I'll see if I can find some time to make the proposals, thanks!
Cheers,
João

[jcristovao]

Hi again,
I'm sorry for the delay on this...
So, the discussion threads:
1
2
Should I send a new email with a summary, just to make sure that everyone is on-board with the latest proposal (your, of separating the Tree from the Forest functions), or the current discussion is sufficient to advance with this?
Cheers,
João

[foxik]

Please reiterate it on libraries list. Just start a new thread with the latest proposal.

I am not saying the Tree/Forest module split is the best alternative, it was just an idea. Please do not hesitate to mention in the proposal also the possibility of distinguishing functions using names only (i.e., using empty vs. Forest suffix (like filter + filterForest), or forest prefix (filter and forestFilter, or anything you come up with).

[m-renaud]

It's been quite some time since this has been updated, was there any resolution on the libraries list for these? If not I was planning on going through the Tree api and putting together a proposal for functions to be added, I can include these in the list.