Adding Fixed Point Data Types to base

Andrew Martin andrew.thaddeus at
Sun Oct 16 15:37:38 UTC 2016

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

On 10/16/16, Michael Walker <mike at> 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 (

-Andrew Thaddeus Martin

More information about the Libraries mailing list