Document relation to freer better

[jberryman]

I'm trying to evaluate the effects ecosystem and was quite confused until I saw an old issue linking to : commercialhaskell/stackage#2239 (comment)

It would be helpful to have a short summary of the situation at the top of the package description (why forked, whether there are plans to merge to upstream, whether changes to freer can be expected to be merged into this package, how it has diverged currently (maybe that's in a changelog, etc.)

In any case, thanks for working on this.

While I'm here, can I ask has using free/your fork worked out well for you? Do you have performance constraints and has the package met them?

[trskop]

I understand your confusion caused by us forking freer, however, I'm not convinced that it's a good idea to reserve such prominent place, in the documentation, for package politics. README already contains Acknowledgements section that clearly states that this package started as a fork of freer.

If you think that something should be added, to clear things up, then send us a PR. We'll be thankful for anything that can help users when picking up freer-effects.

Disclaimer: This is just my personal opinion.

I wasn't part of the original discussion with Allele, but as I understand it, she is unable to invest (unpaid) time into freer. However, she still wants to retain the complete ownership, and the name of the package. She has right to both, of course, but for us it was unacceptable. We were already using freer, and having no way of getting changes upstream forced us to fork it. For this reason we have no plan on merging back into freer. Things may change in the future, but I'm not keeping my hopes up. The longer this situation lasts, the harder it would be, and we've already started to accept incompatible changes, which would make it already quite non-trivial.

Regarding our usage of freer, and freer-effects:

• There is still not much difference, from user perspective, between these two, and our transition to freer-effects was seamless.
• We do have performance constraints, but we are able to differentiate between places where it's essential, and where more abstract tools provide much better cost / performance ratio.
• Transformers and MTL are still used heavily, and I don't think it's reasonable to completely switch to effects. At least not until it's as fast as transformers. Interestingly, PureScript compiler is able to create faster code for them than for monad transformers.
• I think that we would have performance issues if we've switched to something like extensible-effects, but that is just my unproven conjecture.
• Before we've adopted freer, we've made few prototypes in various effect implementations, and freer won due to its nice API. You might be also interested in PR Add benchmarks to compare extensible-effects #19, which added benchmarks comparing freer-effects and extensible-effects.

Hopefully I was able to clear some things up for you. If there is still anything unclear then feel free to ask. Maybe my colleagues will add their points of view as well.

[jberryman]

I understand your confusion caused by us forking freer, however, I'm not convinced that it's a good idea to reserve such prominent place, in the documentation, for package politics.

Well I'm really not interested in politics, but for me the first thing I would have liked to see is something like "freer-effects is a maintained fork of the Allele Dev's freer package which is an implementation of Oleg's blah blah...". That's the single most important piece of context for a newcomer imo. I think that combined with the changelog is enough.

Thanks for the comments, I'll send you a PR with more benchmarks if I end up exploring the package more.