[Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`

Thu Oct 8 18:52:58 UTC 2015

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 10/08/2015 09:55 AM, Ben Gamari wrote:
> Michael Orlitzky <michael at orlitzky.com> writes:
> 
>> (replying to no one in particular)
>> 
>> This problem isn't specific to Haskell. In every other language,
>> you have projects that support major versions of toolkits,
>> compilers, libraries and whatnot. And there's already a tool for
>> it: git.
>> 
>> Instead of using #ifdef to handle four different compilers, keep
>> a branch for each. Git is designed to make this easy, and it's
>> usually trivial to merge changes from the master branch back into
>> e.g. the ghc-7.8 branch. That way the code in your master branch
>> stays clean. When you want to stop supporting an old GHC, delete
>> that branch.
>> 
> I don't find this option terribly appealing. As a maintainer I
> would far prefer maintaining a bit of CPP than a proliferation of
> branches, with all of the cherry-picking and potential code
> divergence that they bring.

It's really not that bad. You only need a separate branch when things
are actually incompatible, so while you may support four versions of
GHC, you might only need two branches.

And the difference between the branches should be exactly what you
have wrapped in an #ifdef right now:

  a) If you're modifying something in an #ifdef, then the change only
     goes in one branch, and you don't have to cherry-pick anything.

  b) If the change wouldn't fall within an #ifdef, then it affects code
     common to all your branches, and the merge will be trivial.

It's annoying to have to do that for every change, so don't. Keep a
pile of common changes in your master branch, and then rebase/merge
the other branches right before you make a release.