I am not opposed to bringing over the helper functions as well. Those are very useful, and I almost always need to tear down `Free` with `iter` or `iterA`. I was trying to keep the scope of the changes down to just the data types for several reasons. - The data types are the only types that library maintainers actually need in order to provide instances. - Some of the helper functions (like _Pure and _Free) have a Choice constraint and require a `profunctors` dependency. As you mention, MonadFree is probably not a good candidate for `base` either. So, to not break people's stuff, we would have to leave `Control.Monad.Free` in `free` (which would basically reexport stuff and provide _Pure and _Free), and we would have to add a module to `base`, something like `Data.Fixed.Free`, which provides definitions for all the functions. Usually, when modules are moved into `base`, it seems like people just move the whole module, but that couldn't be done here. - iterA vs iterM is a relic from the pre-AMP world. It may bother some people to put things from a bygone age into `base`. - Since there is no canonical library that provides `Fix`, we have to figure out which utilities go in there (cata,ana,para,etc.) Personally, I would be happy to see some of those utility functions in base. But, it makes the path forward a little less clear, and it makes it more likely that this proposal will stall. I would love to hear more thoughts on how to make that happen as long as they have some detail to them, detail that address at least the issues that I brought up. I'll end by reiterating that in my mind, the most important thing is getting the data types into base. Anything else is icing on the cake. On 10/16/16, Michael Walker <mike@barrucadu.co.uk> wrote:
All of the other utilities functions from these packages would not be moved to `base`; they would remain in `free`
Importing the types without the functions seems like people would still end up depending on `free` to get those (or copy/paste the definitions). I can understand not wanting to pull the `MonadFree` typeclass and related functions into `base`, but there are a lot of functions in `free` which don't depend on that but are still useful.
-- Michael Walker (http://www.barrucadu.co.uk)
-- -Andrew Thaddeus Martin