Proposal: improve the Data.Tree API

[João Cristóvão]

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 <daniel.trstenjak at gmail.com>:

> 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 at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20140228/4b67f04d/attachment.html>