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

[amindfv at gmail.com]

Another problem with #ifdefs (especially machine-generated ones) is that it makes code much harder to read. One of the things I love about Haskell is the ability to read code and literally see an author describe how they're thinking about the domain. #ifdefs make life less fun :)

Tom


> El 5 oct 2015, a las 21:00, Phil Ruffwind <rf at rufflewind.com> escribió:
> 
> Having so many #ifdefs isn't by itself a major problem.  Yes, it does
> introduce a small increase in compilation time and the size of the
> codebase.  The real cost is the developer time: every developer has to
> come up with these these #ifdef clauses from scratch for every change
> that gets made, tailored to their specific code.  As more and more get
> added, it becomes more and more of a confusing mess.
> 
> It makes me wonder if this can be automated somehow.  It would be nice
> to have a mechanism to alleviate this cost so that most developers
> downstream (provided that the code was written in a reasonable manner)
> only need to make a minimal effort to keep up, while still being able
> to write code that works for a reasonably large range of GHC versions.
> The burden of breaking changes right now is on the downstream
> developers, but perhaps there could be a way to shift most of that
> upstream to avoid this large duplication of effort.
> 
> Haskell should be allowed to evolve, but there also needs to be a
> counterweight mechanism that provides stability in the face of
> constant changes.  It would be something similar in spirit to
> base-compat, but I don't think a library package alone is powerful
> enough to solve the problem: a missing 'return' for example is not
> something a library can just patch in.
> 
> I don't have any preference for "lots of small changes" vs "one big
> change": in the former, there is a lot of overhead needed to keep
> track of and fix these small changes; in the latter, there is a risk
> of introducing a rift that fragments the community (cf Python 2 vs 3).
> Maybe something in-between would be the best.
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries