On 10/22/2015 11:02 AM, Matthias Hörmann wrote: > I would say that the need to import Control.Applicative in virtually > every module manually > definitely caused some pain before AMP.
In this particular case, there is a trade off between breaking code on the one hand and having to write some import statements on the other. I find writing some extra imports less painful than breaking (other people's and my) code, but the other position is defensible as well. I sense that I am in the minority, at least on the libraries list. > I would also argue that a > non-negligible amount > of effort goes into teaching the warts, the reasons for the warts and > how to work around them. Which wart(s) in particular? All of them? Does having return (and (>>)) in Monad make teaching more difficult? I teach Haskell beginners, and I found that AMP made explaining monads slightly more difficult because it served as a source of confusion for my students. On the other hand, the warts provide a teachable moment once students understand all this stuff :) >> Dealing with AMP? I'm working on a collaborative research project that is >> stuck on 7.8 because of AMP. > I am curious what exactly about AMP causes your research project to be > "stuck" on GHC 7.8 > considering we have had multiple people mention how little effort it > took to update even large codebases. > I think it would be useful information to have to plan future changes > in a way that might avoid > your issues. I was hoping that mentioning this wouldn't distract from the three main (numbered) questions I posed below. Alas. If I were working alone, AMP wouldn't be a huge deal. I could fix the code for 7.10 compatibility, but then unless everyone switches to 7.10, changes to the codebase made by someone using 7.8, e.g., defining a new Monad instance, could break things on 7.10 again. It's easier to stick with 7.8. Any time spent dealing with compatibility issues is time not spent writing actual code. I outlined one possible path to avoid this kind of issue: spend more time thinking about ways to maintain compatibility. We had proposals for doing this with AMP. Cheers, Geoff > > On Thu, Oct 22, 2015 at 3:29 PM, Geoffrey Mainland <mainl...@apeiron.net> > wrote: >> On 10/22/2015 02:40 AM, Edward Kmett wrote: >>> On Wed, Oct 21, 2015 at 8:42 PM, Gregory Collins >>> <g...@gregorycollins.net <mailto:g...@gregorycollins.net>> wrote: >>> >>> >>> On Wed, Oct 21, 2015 at 3:18 PM, Geoffrey Mainland >>> <mainl...@apeiron.net <mailto:mainl...@apeiron.net>> wrote: >>> >>> My original email stated my underlying concern: we are losing >>> valuable >>> members of the community not because of the technical >>> decisions that are >>> being made, but because of the process by which they are being >>> made. >>> >>> [If] you're doing research you're on the treadmill, almost by >>> definition, and you're delighted that we're finally making some >>> rapid progress on fixing up some of the longstanding warts. >>> >>> If you're a practitioner, you are interested in using Haskell for, >>> y'know, writing programs. You're probably in one of two camps: >>> you're in "green field" mode writing a lot of new code (early >>> stage startups, prototype work, etc), or you're >>> maintaining/extending programs you've already written that are out >>> "in the field" for you doing useful work. Laura Wingerd calls this >>> the "annealing temperature" of software, and I think this is a >>> nice metaphor to describe it. How tolerant you are of ecosystem >>> churn depends on what your temperature is: and I think it should >>> be obvious to everyone that Haskell having "success" for >>> programming work would mean that lots of useful and correct >>> programs get written, so everyone who is in the former camp will >>> cool over time to join the latter. >>> >>> >>> I've made the point before and I don't really want to belabor it: >>> our de facto collective posture towards breaking stuff, especially >>> in the past few years, has been extremely permissive, and this >>> alienates people who are maintaining working programs. >>> >>> >>> Even among people who purported to be teaching Haskell or using >>> Haskell today in industry the margin of preference for the concrete >>> FTP proposal was ~79%. This was considerably higher than I expected in >>> two senses. One: there were a lot more people who claimed to be in one >>> of those two roles than I expected by far, and two: their appetite for >>> change was higher than I expected. I initially expected to see a >>> stronger "academic vs. industry" split in the poll, but the groups >>> were only distinguishable by a few percentage point delta, so while I >>> expected roughly the end percentage of the poll, based on the year >>> prior I'd spent running around the planet to user group meetings and >>> the like, I expected it mostly because I expected more hobbyists and >>> less support among industrialists. >>> >>> I'm actually firmly of the belief that the existing committee >>> doesn't really have process issues, and in fact, that often it's >>> been pretty careful to minimize the impact of the changes it wants >>> to make. As others have pointed out, lots of the churn actually >>> comes from platform libraries, which are out of the purview of >>> this group. >>> >>> >>> Historically we've had a bit of a split personality on this front. >>> Nothing that touches the Prelude had changed in 17 years. On the other >>> hand the platform libraries had maintained a pretty heavy rolling wave >>> of breakage the entire time I've been around in the community. On a >>> more experimental feature front, I've lost count of the number of >>> different things we've done to Typeable or template-haskell. >>> >>> >>> All I'm saying is that if we want to appeal to or cater to working >>> software engineers, we have to be a lot less cavalier about >>> causing more work for them, and we need to prize stability of the >>> core infrastructure more highly. That'd be a broader cultural >>> change, and that goes beyond process: it's policy. >>> >>> >>> The way things are shaping up, we've had 17 years of rock solid >>> stability, 1 release that incorporated changes that were designed to >>> minimize impact, to the point that the majority of the objections >>> against them are of the form where people would prefer that we broke >>> _more_ code, to get a more sensible state. Going forward, it looks >>> like the next 2 GHC releases will have basically nothing affecting the >>> Prelude, and there will be another punctuation in the equilibrium >>> around 8.4 as the next set of changes kicks in over 8.4 and 8.6 That >>> gives 2 years worth of advance notice of pending changes, and a pretty >>> strong guarantee from the committee that you should be able to >>> maintain code with a 3 release window without running afoul of >>> warnings or needing CPP. >>> >>> So, out of curiosity, what additional stability policy is it that you >>> seek? >> Thanks to you and Dan [1], I now have a greater understanding and >> appreciation for where the committee has been coming from. My new >> understanding is that the changes that were formalized in AMP, FTP, and >> MRP were the basis for the committee's creation. It also seems that >> there are more changes in the pipeline that have not yet been made into >> proposals, e.g., pulling (>>) out of Control.Monad [2]. Part of >> "stability" is signaling change as far ahead as possible. The committee >> has put a lot of effort into this, which I appreciate! However, as each >> of these proposal has come down the pipeline, I never realized that they >> were part of a larger master plan. >> >> 1) What is the master plan, and where is it documented, even if this >> document is not up to the standard of a proposal? What is the final >> target, and when might we expect it to be reached? What is in the >> pipeline after MRP? >> >> Relatedly, guidance on how to write code now so that it will be >> compatible with future changes helps mitigate the stability issue. >> >> 2) How can I write code that makes use of the Prelude so that it will >> work with every new GHC release over the next 3 years? 5 years? For >> example, how can I write a Monad instance now, knowing the changes that >> are coming, so that the instance will work with every new GHC release >> for the next 3 years? 5 years? If the answer is "you can't," then when >> might I be able to do such a thing? As of 8.4? 8.6? I'm embarrassed to >> say I don't know the answer! >> >> Finally, if none of these changes broke Prelude backwards compatibility, >> far fewer people would be complaining :) Of course, we can't always make >> progress without breaking things, but a more deliberative process might >> offer an opportunity to make progress while still preserving backwards >> compatibility. Take AMP for example. There were at least two [3] [4] >> proposals for preserving backwards compatibility. Investigating them >> would have taken time and delayed AMP, yes, but why the rush? >> >> 3) Can we have a process that allows more deliberation over, and wider >> publicity for, changes that break backwards compatibility? The goal of >> such a process would not be to prevent change, but to allow more time to >> find possible solution to the issue of backwards compatibility. >> >> My proposal for a low-traffic mailing list where all proposals were >> announced was meant to provide wider publicity. >> >> Personally, I think these proposals do indeed fix a lot of warts in the >> language. As a researcher who uses actively uses Haskell every day, >> these warts have had approximately zero impact on me for the past >> (almost) decade, and I would be perfectly content if they were never >> fixed. The only pain I can recall enduring is having to occasionally >> write an orphan Applicative instance. I have been importing Prelude >> hiding mapM for years. I have been importing Control.Applicative for >> years. Neither has been painful. Dealing with AMP? I'm working on a >> collaborative research project that is stuck on 7.8 because of AMP. I >> agree, that seems silly, but whether or not it is silly, it is an impact >> I feel. >> >> One way to look at these proposals is to ask the question "Wouldn't the >> language be nicer if all these changes were made?" Another is to ask the >> question "Does the fact that these changes have not been made make your >> life as a Haskell programmer more difficult in any significant way?" I >> answer "yes" to the former and "no" to the latter. Is our stance that >> answering "yes" to the former question is enough to motivate braking >> change? Shouldn't a answer "no" to the latter question cause some >> hesitation? >> >> Maybe there are a lot of people who answer "yes" to both questions. I >> would like to know! But does having return in the Monad class really >> cause anyone anything other than existential pain? >> >> Cheers, >> Geoff >> >> [1] https://mail.haskell.org/pipermail/libraries/2015-October/026390.html >> [2] https://mail.haskell.org/pipermail/libraries/2015-September/026158.html >> [3] https://ghc.haskell.org/trac/ghc/wiki/InstanceTemplates >> [4] https://ghc.haskell.org/trac/ghc/wiki/IntrinsicSuperclasses _______________________________________________ Haskell-prime mailing list Haskell-prime@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
