Proposal: improve the Data.Tree API

[Milan Straka]

Hi all,

> -----Original message-----
> From: Johan Tibell <johan.tibell at gmail.com>
> 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 <jmacristovao at gmail.com>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 <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
> >>
> >
> >
> > _______________________________________________
> > Libraries mailing list
> > Libraries at haskell.org
> > http://www.haskell.org/mailman/listinfo/libraries
> >
> >