[Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`
mwm at mired.org
Tue Oct 6 07:58:29 UTC 2015
On Tue, Oct 6, 2015 at 2:40 AM Bardur Arantsson <spam at scientician.net>
> > - To use functions like "tryReadMVar", "unsafeShiftR", and
> > "atomicModifyIORef'" that are in recent base versions but not older
> > (this is a place where CPP use is actually justified)
> Well, yeah, new functions don't magically appear in old versions. I
> don't anybody expects that :).
Right - they have to be backported, and imply maintenance of multiple
Python has been mentioned a couple of times. They did that, backporting
functions that mimiced Python 3 functions to later Python 2 versions, which
made the tools mentioned possible, or at least more capable.
I'll refer those wanting fewer breaking changes to Python. Getting language
changes accepted by the PYthon community is *hard*. You need a use case for
your change, you need to show that the case can't be handled cleanly by the
language as it exists today, that it's common enough to justify the change,
and that it won't tempt people to write uglier code than the current
solution. If you want to break old code, all those bars get raised - a lot.
Or did, anyway, The result of following that was the Python 2/Python 3
split, which I don't think anybody thought was a good thing. Unavoidable,
maybe - Python 3 had to break backwards compatibility, so they cleaned up
everything along the way, and created tools to migrate code, and committed
to maintaining both versions for an extended period of time. And the
community was pretty badly splintered by this.
The one thing I think they got right is documenting the language change
process with the entire PEP process. We seem to have wiki pages, with no
editorial oversight, and pages show up in google searches after they've
been incorporated into the language in a different form. Not quite as good
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Haskell-Cafe