Proposal: improve the Data.Tree API

Yitzchak Gale gale at sefer.org
Thu Jan 1 15:27:33 UTC 2015


Henning Thielemann wrote:
>> What is bad about two imports?

João Cristóvão wrote:
> It is a breaking change from the current Data.Tree API...
> would imply turning:
> Data.Tree.unfoldTree  -> Data.Tree.unfold
> Data.Tree.unfoldForest -> Data.Tree.Forest.unfold
> Thus breaking existing code.

I didn't envision this as being a breaking change,
at least not immediately. I think the idea is:

1. Leave everything currently in Data.Tree as it is.

2. For new functions that apply to trees, put them
into Data.Tree, and if there are versions of those
that apply to forests, put those into Data.Tree.Forest
with the same name.

3. For existing functions in Data.Tree that explicitly
include "Tree" or "Forest" as part of the function name,
provide aliases using the above scheme. Perhaps mark
the old versions as deprecated, but don't get rid of them
yet.

4. Use Henning's internal module trick to work around
circular module dependencies, re-exporting and/or renaming
functions in the modules they need to appear in for the API.

Also, re-export Forest itself from Data.Tree.Forest, just
because if we don't it would look silly.

Thanks,
Yitz


More information about the Libraries mailing list