Re: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`
Hello all, I agree with Henrik, I'm very keen on giving the new Haskell committee a shot. 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.
Best wishes,
José Manuel
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
On Tue, Oct 6, 2015 at 1:39 PM, Tom Ellis < tom-lists-haskell-cafe-2013@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
_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
On 10/07/2015 12:56 AM, José Manuel Calderón Trilla wrote:
Hello all,
I agree with Henrik, I'm very keen on giving the new Haskell committee a shot.
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.
I didn't mean to be too negative about Haskell2010 -- I think Haskell2010 *was* a success, albeit a *limited* one, but I'm doubtful that these things can be designed by committee, especially without prototypes. The C++ community has realized this since C++11 was finalized and are pursuing a much more aggresive evolution of both the language and standard libraries as a consequence -- it has practically become a requirement to have a working prototype in at least one compiler before a language extension/change is even considered. C++ had been completely stagnant since 1998 and there were some disasterous decisions as a result of design-by-committee. "template export", nuff said. That the new Haskell' committee is being spearheaded by the apparently-untiring HVR does inspire some confidence, but as I say... we'll see :). I'm actually an optimist, but I've just been disappointed soooo many times... Regarding the textbook/course argument: Look, I think(!) I understand what you're saying, but any serious developer these days is going to be *used* to adapting to change. *Everything* in practical (full-stack) development these days changes so fast that it doesn't matter whether Monad loses "return" or not. Do you have any idea how fast frontend (JavaScript, mainly) developers have to (and are!) adapting to change? I'm not saying it's necessarily a good thing, but it's happening and people are used to it. There are backwards-incompatible changes in e.g. React almost tri-monthly[1] and yet people adapt even though this is in a *dynamically type-checked* language! (Besides, I didn't expect university to teach me anything practical as in "trade school". I wanted to learn *principles* and *ideas*.) I can also sympathize with *educators* having to adapt their course materials and such, but I think that should be par for the course...? Please consider that the the way practical development really happens[2] has changed and that the argument for stability has shifted somewhat. Regards, Bárður [1] A rough guesstimation of the pace. They have a deprecation period of 1 release. I have to say that Facebook are also dogfooding, I think the 0.14 release post says that they have something like 15000(!) React components at this point. [2] I guess I should qualify that with "... in code bases <1 MLOC", but would that might be a bit snarky? :)
On 10/07/2015 10:54 PM, Bardur Arantsson wrote:
That the new Haskell' committee is being spearheaded by the apparently-untiring HVR [...]
Sorry, I should have continued: ... and hopefully joined by some motivated, skilled and experienced individuals if the self-nominations are anything to go by[1]. I'm a bit unclear on who gets to vote for the nominees, but maybe I missed something. Maybe we're working towards representative democracy here :) Still... I remain skeptical of committees unless they delegate to sub-committees (like "new C++" is doing). Regards, [1] I'm not sure who was on the old Haskell' committe, but I'm absolutely sure the same could have been said of them.
On Wed, Oct 7, 2015 at 4:54 PM, Bardur Arantsson
Please consider that the the way practical development really happens[2]
...among web developers, who of course are the only real developers? Have you considered that there are developers who are not web developers? The past day has convinced me that the web devs have relegated everyone else to fake-non-programmer status and actively want them out of the community because fake programmers don't benefit you real programmers. I had heard that the financial users generally refused to have anything to do with the Haskell community. Now I know why. I wonder how many of them, if any indeed are left after past breaking changes, are in the process of switching to OCaml. I'm sure you consider that a good thing, because they're obviously just holding back "real programmers". -- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net
participants (3)
-
Bardur Arantsson -
Brandon Allbery -
José Manuel Calderón Trilla