The transformers situation

[sjshuck]

In assessing the open issues for mtl, a number of them are blocked on upstream changes to transformers. I emailed @RossPaterson and got an email with point-wise responses ranging from 1) informing of immediate action taken in his darcs repo to 2) expressing concerns/asking for clarification to 3) not responding at all. In that third category is a point I raised about whether there is a plan for others to assist in maintaining. A follow-up email I sent has not been replied to. Attempts to @ him on this site have been unsuccessful. Additionally the darcs hub issues discussions have gone largely unaddressed, both mine and of another user I spoke to.

At this point I think it would be good for the community to discuss maintaining the code independently in this org, either by Git-ifying the repo, preserving history (if possible, haven't investigated) or starting afresh.

None of this is to take away from the clearly great work that Ross has done for the community—in fact, still does to some measure. He is of course urged to participate in this discussion.

[hasufell]

CCing CLC @angerman @parsonsmatt @velveteer @TeofilC @Daniel-Diaz @ChickenProp @noughtmare @mpscholten @doyougnu

[hasufell]

Before I try to assess the situation in more detail, I want to clarify in general:

• maintainers can host their code anywhere they want (or nowhere at all). We only require that there is a clear process of contributing and discussing patches (that can be via email as well)
• we require the library to be well-maintained and contributions to be considered... as long as that holds, we don't have any other requirements (e.g. they don't have to accept new co-maintainers and they also don't have to accept patches... as long as there's a reasonable response/review)

---

Now... I can see that transformers and mtl are quite intertwined. Can you describe in more detail what exactly is causing the tension? I don't think most of us have an overview of the interactions. Is there some fundamental design disagreement?

[sjshuck]

No fundamental disagreements.

In short, there is a growing backlog, both in transformers itself and in mtl, where problems just seem unfixable due to maintainer intransigence. See this discussion for example.

[Bodigrim]

In principle mtl is free to provide more or less than transformers package does and is not obliged to mirror its structure, so potentially mtl can lead the way and resolve pretty much all the tickets without touching transformers. I'd probably do just this, if I were you.

[sjshuck]

I would like to avoid as much as possible the option of bypassing transformers and putting things in mtl where they don't belong. It does solve the problem, but creates new ones. In the above example, both libraries would have liftCallCC which serve the exact same use case but have slightly different semantics that cause hard-to-trace bugs to arise in a user's code if they happened to import it from Control.Monad.Trans.Reader instead of Control.Monad.Cont.Class. And there's no technical reason for this.

I really like the fact that transformers is transformers, and mtl re-exports it and provides typeclasses. It would be a shame to water down or abandon that design.

[parsonsmatt]

Just to be clear, are you suggesting that we do a Package Takeover on a somewhat actively maintained transformers package because you and others disagree with his choices as a maintainer?

[sjshuck]

If it was just disagreement, that'd be one thing. But it's also an issue of

contributions to be considered

and

reasonable response/review

Here's a demonstration of that: Eventually I would like to reimplement the Strict Writer modules to be a re-export of the CPS Writer modules and deprecate "CPS". I keep encountering libraries providing mtl-style classes with instances for the Lazy and Strict transformers and leaving out CPS, which is the actually good strict one, whereas "Strict" is always bad. Clearly that's a big change, although it may not actually be a breaking change. After failing to get transformers' maintainer's attention through GitHub or Darcs Hub, I sent him an email about this among other items. He replied, asking for clarification. After I provided it, he did not respond at all.

Now, there are any number of possible reasons why someone would not agree with that change, whether in theory, implementation, impact to users/reverse dependencies, etc. But to not address it at all is a problem IMO. Even the fact that I have to relay private email correspondence for the business of maintaining a rev dep in a community-driven fashion is a problem.

In this example @Bodigrim would you suggest I re-export Control.Monad.Trans.Writer.CPS within Control.Monad.Writer.Strict?

[Bodigrim]

In this example @Bodigrim would you suggest I re-export Control.Monad.Trans.Writer.CPS within Control.Monad.Writer.Strict?

Yes, if I were you I would seriously consider such approach. Not ideal, of course, but an entirely possible course of actions IMO.

---

In the interest of eliminating points of failure and cultivating open collaboration, there is a certain "inaccessibility budget". Say, a large group of maintainers can have no public issue tracker and accept patches via email and still clear the mark. A single active and responsive maintainer can operate a boutique issue tracker such as Darcs to no detriment of contributors and community. But if time and interest become scarcier, I think that moving to Git / GitHub could be used to compensate for deficiencies in other areas.

[hasufell]

I agree that doesn't sound ideal, but CLC is usually only there to resolve issues with egregious lack of maintenance.

Otherwise we try to stay out of the way.

I can however try to contact the maintainer and see whether I can get clarification on their position of adding co-maintainers and how to resolve the entanglement of mtl and transformers.

[sjshuck]

I would seriously consider such approach

👍 I'll think about it.

only there to resolve issues with egregious lack of maintenance

Yep. I don't want to overstate the case; I agree it's not egregious.

try to contact the maintainer

I appreciate the effort. Thanks all for the discussion so far.

[doyougnu]

first I want to say @sjshuck thanks for opening this issue, putting in the work facilitating it, and working to improve the ecosystem. I understand your concern and the position the transformers package puts you in.

However, looking at the transformers changelog the last commit was September 18th of this year. transformers looks well maintained to me with regular updates. I cannot call this a case of abandonment. As far as I can tell most of the issues are enhancements of one type or another instead of bug reports.

I really like the fact that transformers is transformers, and mtl re-exports it and provides typeclasses. It would be a shame to water down or abandon that design.

I completely agree, but the suggestion of taking over a package, even if that package is part of critical infrastructure is IMHO an act of arbitrary authority that would violate the autonomy of all contributors of Haskell packages in the open source ecosystem. As you've reported Ross has considered some of the proposed changes and has, as is his right to do, decided not to act on them because they disagree with his design philosophy. Could he be more communicative, sure, but his actions are reasonable to me even in the face of the downstream issues they create. Taking over such a package without his consent would violate Ross' stewardship of his own library and would create a real and manifest social hazard.

I understand that this is frustrating, but I view the proposed cure as worse than the disease.

No fundamental disagreements.
In short, there is a growing backlog, both in transformers itself and in mtl, where problems just seem unfixable due to maintainer intransigence. See haskell/mtl#127 for example.

This is not true. There are fundamental disagreements about what "Standard Haskell" is, and those disagreements directly influence the design of the types in transformers which in turn leads to the referenced backlog of proposed changes. The maintainer intransigence seems to me to more of a communication issue, e.g., not closing tickets as wontdo than a maintenance issue.

[sjshuck]

Thanks for the thoughtful response @doyougnu. I'm satisfied that a takeover isn't worth pushing for. I'll leave it to the maintainers to close this issue if desired.

After further private discussion I decided to leave the relevant mtl issues blocked. There is no urgency.