Proposal: improve the Data.Tree API

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