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

[Mario Blažević]

On 10/09/2015 03:29 AM, Sven Panne wrote:
> 2015-10-09 2:34 GMT+02:00 David Thomas <davidleothomas at gmail.com 
> <mailto:davidleothomas at 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.