Proposal: improve the Data.Tree API

[João Cristóvão]

Hi Yitz,

Thanks for bringing this up again! Indeed I ended up not pursuing this, not
so much for lack of interest but more due to lack of time.

And besides:

> Based on the discussion then, I recommend that we add
> to the haddock comments a note that some of the
> functions are simple uses of the Comonad instance for
> Tree, and several more variations can easily be built
> using the duplicate and extend functions from the
> comonad library.

This is something that I'm not qualified to explain, and I would love to
see someone more knowledgeable write this up.

So, as I find myself yet again with no opportunity to pursue this, please
feel free to take ownership of my proposal.

For the record, nevertheless, I was moving along with the separate
Tree/Forest modules to avoid further bikeshedding, but to be honest I don't
really see a big advantage - if your using one, you most probably will also
need to use the other, so why two imports?

Thanks,
João


2014-12-28 23:38 GMT+00:00 David Feuer <david.feuer at gmail.com>:

> Oh, I see what you mean now! We could probably put *everything* in the
> private module and then use the public ones just for names. That seems
> fine.
>
> On Sun, Dec 28, 2014 at 6:04 PM, Yitzchak Gale <gale at sefer.org> wrote:
> > David Feuer wrote:
> >> A relevant change has occurred since this proposal came out: `length`
> >> got added to `Foldable`, with semantics that seem to match this
> >> `size`. In light of this, I think `size` should probably be dropped,
> >> and the `Foldable` instance expanded to give a better `length`.
> >
> > Sounds good.
> >
> >> Aside from that, someone just has to put together a pull request for
> >> haskell/containers on GitHub.
> >
> > OK. João was the original owner; let's see if he wants to
> > follow through.
> >
> >> The hardest part of this whole thing
> >> would be the module split. I don't personally see the point—trees are
> >> made of forests, which are made of trees, so while you *could* use
> >> Henning's trick to avoid cycles, you'd likely end up putting much of
> >> the code in Data.Tree.Private (to avoid orphan instances) and then end
> >> up with everyone exporting both public modules. For now, even with the
> >> proposed additions, Data.Tree is quite a small module, so I don't know
> >> why we should go to the trouble.
> >
> > As discussed at the time - the consistent naming convention
> > throughout the containers library is to avoid using names of
> > types as parts of function names. Instead, separate modules are
> > used to qualify the same name for functions that do the same
> > thing. The module split was proposed to comply with that
> > convention, and no one expressed any opposition.
> >
> > However, personally I'm also fine with using João's original
> > names to avoid the module split. What's important to me is
> > getting these long-overdue combinators into the library as
> > soon as possible, without arguing over the names.
> >
> > Thanks,
> > Yitz
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20141231/50451ba5/attachment.html>