[Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`
blamario at ciktel.net
Fri Oct 9 12:57:17 UTC 2015
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-220.127.116.118
and my-package-18.104.22.1680. 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
on ghc-7.8 branch
build-depends: ghc <= 7.8.*,
on ghc-7.10 branch
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
git checkout ghc-7.10
git merge master
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.
More information about the Haskell-Cafe