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