Re: Proposal: improve the Data.Tree API

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 :

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 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