[Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`
José Manuel Calderón Trilla
jmct at jmct.cc
Tue Oct 6 22:56:47 UTC 2015
I agree with Henrik, I'm very keen on giving the new Haskell committee a
While some may not think that Haskell2010 was a success, I think it would
be difficult to argue that Haskell98 was anything but a resounding success
(even if you don't think the language was what it could have been!).
Haskell98 stabilized the constant changes of the proceeding 7 years. The
stability brought with it books and courses, and the agreed-upon base of
the language allowed _research_ to flourish as well. Having an agreed base
allowed the multiple implementations to experiment with different methods
of implementing what the standard laid out.
Many of us here learned from those texts or those courses. It's easy online
to say that materials being out of date isn't a big deal, but it can turn
people off the language when the code they paste into ghci doesn't work. We
use Haskell for the compilers course at York; Haskell is the means, not the
end, so having to update the materials frequently is a significant cost. It
can be difficult to defend the choice of using Haskell when so much time is
spent on something that 'isn't the point' of the course.
Does that mean that we should never change the language? Of course not, but
this constant flux within Haskell is very frustrating. Maybe Haskell2010
wasn't what everyone wanted it to be, but that does not mean the _idea_ of
a committee is without merit. Having controlled, periodic changes that are
grouped together and thought through as a coherent whole is a very useful
thing. One of the insights of the original committee was that there would
always be one chair at any point in time. The chair of the committee had
final say on any issue. This helped keep the revisions coherent and ensured
that Haskell made sense as a whole.
Lastly, I'd like to quote Prof. Runciman from almost exactly 22 years ago
when the issue of incompatible changes
came up. His thoughts were similar to Johan's:
On 1993-10-19 at 14:12:30 +0100, Colin Runciman wrote:
> As a practical suggestion, if any changes for version 1.3 could make
> some revision of a 1.2 programs necessary, let's have a precise
> stand-alone specification of these revisions and how to make them.
> It had better be short and simple. Many would prefer it to be empty.
> Perhaps it should be implemented in Haskell compilers?
Overall I don't see the rush for these changes, let's try putting our faith
in a new Haskell committee, whomever it is comprised of.
P.S. A year ago Prof. Hinze sent me some Miranda code of his from 1995 as I
was studying his thesis. I was able to run the code without issue, allowing
me to be more productive in my research ;-)
On Tue, Oct 6, 2015 at 2:29 PM, Gregory Collins <greg at gregorycollins.net>
> On Tue, Oct 6, 2015 at 1:39 PM, Tom Ellis <
> tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk> wrote:
>> In fact I think all of these apart from the FFI one could be solved with a
>> -compat package, could they not?
> Who cares? In practice, the programs break and I have to fix them. Most of
> the time, CPP is the lowest-friction solution -- if I rely on a -compat
> package, first I have to know it exists and that I should use it to fix my
> compile error, and then I've added an additional non-platform dependency
> that I'm going to have to go back and clean up in 18 months. Usually, to be
> honest, *actually* the procedure is that the new RC comes out and I get
> github pull requests from hvr@ :-) :-)
> In response to the other person who asked "why do you want to support so
> many GHC versions anyways?" --- because I don't hate my users, and don't
> want to force them to run on the upgrade treadmill if they don't have to?
> Our policy is to support the last 4 major GHC versions (or 2 years,
> whichever is shorter). And if we support a version of GHC, I want our
> libraries to compile on it without warnings, I don't think that should
> mystify anyone.
> Gregory Collins <greg at gregorycollins.net>
> Libraries mailing list
> Libraries at haskell.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Haskell-Cafe