
Hi all,
-----Original message----- From: Johan Tibell
Sent: 28 Feb 2014, 14:11 OK. That sounds fine by me. Milan?
I like lookupTree (being the one who suggested that), as it is returning a Tree. But maybe it would be better to have lookupTreeBy instead of findTree -- when you see lookupTree and lookupTreeBy, it is quite obvious how they differ. If I saw lookupTree and findTree, I would have to see the docs to find the difference. I am nevertheless not convinced about lookupTreeInForest -- the name seems too long. Also, many other functions could be applied to Forest -- filterForest, pruneForest, forestSize, ... Just a wild idea -- if we want to export more functions working with Forest a, what if we added Data.Tree.Forest module, and export from there? The functions would then have the same name as the Tree counterparts. Cheers, Milan
On Fri, Feb 28, 2014 at 1:10 PM, João Cristóvão
wrote: I'm with Sean here,
In Data.Map, for example, the lookup function returns the type Maybe a, not Data.Map k a. And find, in Data.Foldable (for which Tree has an instance) also returns a Maybe a.
But the lookupTree/findTree/lookupTreeInForest functions return Maybe (Tree a), thus I added the final 'Tree' in the name.
The only function name where that did not apply was filter, since (for example) for lists the filter function also returns the type of the original container, not the inner type.
This was the rationale I followed. I'm afraid that renaming findTree to findBy will be confusing, as it seems that you just provide a 'evaluator function', but still return the inner type a (like find), instead of the (actual) Tree a.
Cheers, João
2014-02-27 15:27 GMT+00:00 Daniel Trstenjak
: On Thu, Feb 27, 2014 at 03:05:00PM +0100, Henning Thielemann wrote:
Yes please, but I already got lots of resistance for a qualifiable name in Data.Bits.
I really think that 'Data.Bits' is a bit special in this regard with all of its functions, which are often used with back ticks and importing all of them explicitely is really a bit annoying.
Otherwise I'm with you :).
Greetings, Daniel _______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries
_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries