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