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

On 10/09/2015 03:29 AM, Sven Panne wrote:

2015-10-09 2:34 GMT+02:00 David Thomas mailto:davidleothomas@gmail.com>:

No, and I'm not sure just how well existing Hackage tooling/process matches the workflow (due mostly to ignorance of existing Hackage tooling/process). To the degree that there's a mismatch, it may have reason sufficient to abandon the approach - or it may suggest improvements to tooling/process.

To be honest, I can't really see how git can help with the versioning issue at all. Let's think backwards: In the end, you must give your compiler a single version of your code which works with. The common solution for this is to run something before the actual compilation stage (preprocessing), which picks the right parts from a single source. Let assume that we don't want this preprocessing step, then you still have to give your compiler a single correct version of your sources. How do you want to accomplish that? Shipping separate source packages (be it via Hackage or through some other means) for each version?

Via Hackage. Let's say my-package is at version 1.7.2 as far as features and bug fixes go; Hackage would then host my-package-1.7.2.708 and my-package-1.7.2.710. The former is uploaded by running cabal upload on branch ghc-7.8 of the source repository, the latter on branch ghc-7.10. The main difference between the branches would be in the .cabal file: on ghc-7.8 branch version: my-package-1.7.2.708 build-depends: ghc <= 7.8.*, on ghc-7.10 branch version: my-package-1.7.2.710 build-depends: ghc == 7.10.*, You can do this with no extra tooling, the only extra work is to run seven commands instead of one at publishing time: git checkout ghc-7.8 git merge master cabal upload git checkout ghc-7.10 git merge master cabal upload git checkout master Obviously it would be better to script this, or even to add support directly to cabal-install and stack.

This would be maintenance hell and much work, especially when there is no 1:1 correspondence between branches and compilers/libraries (as was proposed above). Furthermore, having to remember which stuff has been merged where, solving merge conflicts, introducing new branches when compilers/libraries change, etc. etc. requires extensive bookkeeping beyond git, to such an extent that larger companies normally have several people working full-time on such non-technical stuff. This is definitely not the way to go when you want to encourage people to work on their free time in Haskell.

I really don't see what could possibly cause all that complexity. Conflicts between different GHC branches and master development branch should be minimal, with any care.

In a nutshell: IMHO having #ifdefs in the code is the lesser evil. If somebody has a better, actually working idea, he can probably become a millionaire quickly by selling this to the industry...

The industry can be remarkably reluctant to take up a new idea; nobody has ever been fired for using #ifdef.