October 2015 - Haskell-prime

Re: Breaking Changes and Long Term Support Haskell
by Geoffrey Mainland 22 Oct '15

22 Oct '15

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 <mainland(a)apeiron.net> wrote: >> On 10/22/2015 02:40 AM, Edward Kmett wrote: >>> On Wed, Oct 21, 2015 at 8:42 PM, Gregory Collins >>> <greg(a)gregorycollins.net <mailto:greg@gregorycollins.net>> wrote: >>> >>> >>> On Wed, Oct 21, 2015 at 3:18 PM, Geoffrey Mainland >>> <mainland(a)apeiron.net <mailto:mainland@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

4 8

Re: Breaking Changes and Long Term Support Haskell
by Edward Kmett 22 Oct '15

22 Oct '15

On Thu, Oct 22, 2015 at 1:37 PM, Gregory Collins <greg(a)gregorycollins.net> wrote: > > On Wed, Oct 21, 2015 at 11:40 PM, Edward Kmett <ekmett(a)gmail.com> wrote: > >> 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 >> > > I have >95% confidence that all of the C++ programs I wrote 15 years ago > would build and work if I dusted them off and typed "make" today. I have > Haskell programs I wrote last year that I probably couldn't say that about. > > So I don't buy that, at all, at least if we're discussing the topic of the > stability of the core infrastructure in general rather than changes being > made to the Prelude. It's been possible to write to Haskell 98 without too > much breakage, yes, but almost nobody actually does that; they write to > Haskell as defined by GHC + the boot libraries + Haskell platform + > Hackage, IMO with decreasing expectations of stability for each. The core > set breaks a lot. > I definitely agree here. We have a lot of libraries in the Haskell Platform that have fairly liberal change policies. On the other hand, we have a policy of "maintainer decides" around issues. This yields a fairly decentralized change management process, with different maintainers who have different views. The Platform gives us a central pool of packages that are generally the "best of breed" in their respective spaces, but gives us few stability guarantees. Heck, every release I wind up having to change whatever code I have that uses template-haskell or Typeable. On the other hand, it isn't clear with a larger "core" platform with harder stability guarantees that we have a volunteer force that can and would sign up for the long slog of maintenance without that level of autonomy. > We definitely shouldn't adopt a posture to breaking changes as > conservative as the C++ committee's, and literally nobody in the Haskell > community is arguing against breaking changes in general, but as I've > pointed out, most of these breakages could have been avoided with more > careful engineering, and indeed, on many occasions the argument has been > made and it's fallen on deaf ears. > I would argue that there are individual maintainers that give lie to that statement. In many ways Johan himself has served as a counter-example there. The libraries he has maintained have acted as a form of bedrock with long maintenance windows. On the other hand, the burden of maintaining that stability seems to have ultimately burned him out. They can speak for themselves but I think for Mark and Johan, this is a > "straw that broke the camel's back" issue rather than anything to do with > the merits of removing return from Monad. I think the blowback just happens > to be so much stronger on MRP because the breaking change is so close to > the core of the language, and the benefits are so nebulous. fixing an > aesthetic problem has almost zero practical value > I personally don't care about the return side of the equation. Herbert's MRP proposal was an attempt by him to finish out the changes started by AMP so that a future Haskell Report can read cleanly. Past reports have been remarkably free of historical baggage. I'd personally readily sacrifice "progress" there in the interest of harmony. Herbert as haskell-prime chair possibly feels differently. > and ">> could be slightly more efficient for some monads" is pretty weak > sauce. > The issue right now around (>>) is that it has knock-on effects that run pretty far and wide. "Weak sauce" or not, it means through second order consequences that we can't move the useless mapM and sequence to the top level from their current status as memberrs of Traversable and that users have to care about which of two provably equivalent things that they are using, at all times. It means that code that calls mapM will be less efficient and that mapM_ behaves in a manner with rather radically different space and time behavior than mapM today and not in a consistently good way. -Edward

1 0

Re: Breaking Changes and Long Term Support Haskell
by Edward Kmett 22 Oct '15

22 Oct '15

On Wed, Oct 21, 2015 at 8:42 PM, Gregory Collins <greg(a)gregorycollins.net> wrote: > > On Wed, Oct 21, 2015 at 3:18 PM, Geoffrey Mainland <mainland(a)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? -Edward

3 4

Re: Breaking Changes and Long Term Support Haskell
by Taru Karttunen 22 Oct '15

22 Oct '15

On 21.10 17:42, Gregory Collins wrote: > 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. I think that how the changes are handled can make a large difference. E.g. if A) Most of Hackage (including dependencies) compiles with new GHC. (stack & stackage helps somewhat) B) There is an automated tool that can be used to fix most code to compile with new versions of GHC without warnings or CPP. C) Hackage displays vocally what works with which versions of GHC (Status reports do help somewhat) Then I think much of the complaints would go away. - Taru Karttunen

3 3

Re: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`
by Henrik Nilsson 22 Oct '15

22 Oct '15

Hi all, Geoffrey Mainland wrote; > What worries me most is that we have started to see very valuable > members of our community publicly state that they are reducing their > community involvement. That worries me too. A lot. To quote myself from an earlier e-mail in this thread: > Therefore, please let us defer further discussion and > ultimate decision on MRP to the resurrected > HaskellPrime committee, which is where it properly > belongs. Otherwise, the Haskell community itself might > be one of the things that MRP breaks. Geoffrey further wrote: > Proposal 3: A decision regarding any proposal that significantly > affects backwards compatibility is within the purview of the Haskell > Prime Committee, not the Core Libraries Committee. I thus definitely support this, at least for anything related to the libraries covered by the Haskell report. Indeed, I strongly suspect that many people who did not actively follow the libraries discussions did so because they simply did not think that changes to the central libraries as defined in the Haskell report, at least not breaking changes, were in the remit of the libraries committee, and were happy to leave discussions on any other libraries to the users of those libraries. And as a consequence they were taken by surprise by AMP etc. So before breaking anything more, that being code, research papers, books, what people have learned, or even the community itself, it is time to very carefully think about what the appropriate processes should be for going forward. Best, /Henrik -- Henrik Nilsson School of Computer Science The University of Nottingham nhn(a)cs.nott.ac.uk This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation.

8 14

Committee M.O. Change Proposals (was: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`)
by Herbert Valerio Riedel 21 Oct '15

21 Oct '15

Hello, On 2015-10-21 at 02:39:57 +0200, Geoffrey Mainland wrote: [...] > In effect, only those who actively follow the libraries list have had a > voice in these decisions. Maybe that is what the community wants. I hope > not. How then can people like me (and Henrik and Graham) have a say > without committing to actively following the libraries list? > > We have a method to solve this: elected representatives. Right now the > Core Libraries Committee elects its own members; perhaps it is time for > that to change. [...] > Proposal 1: Move to community election of the members of the Core > Libraries Committee. Yes, I know this would have its own issues. How exactly do public elections of representatives address the problem that some people feel left out? Have you considered nominating yourself or somebody else you have confidence in for the core libraries committee? You'd still have to find somebody to represent your interests, regardless of whether the committee is self-elected or direct-elected. Here's some food for thought regarding language design by voting or its indirect form via a directly elected language committee: Back in February there was a large-scale survey which resulted (see [2] for more details) in a rather unequivocal 4:1 majority *for* going through with the otherwise controversial FTP implementation. If the community elections would result in a similar spirit, you'd could easily end up with a similarly 4:1 pro-change biased committee. Would you consider that a well balanced committee formation? > Proposal 2: After a suitable period of discussion on the libraries list, > the Core Libraries Committee will summarize the arguments for and > against a proposal and post it, along with a (justified) preliminary > decision, to a low-traffic, announce-only email list. After another > suitable period of discussion, they will issue a final decision. What is > a suitable period of time? Perhaps that depends on the properties of the > proposal, such as whether it breaks backwards compatibility. That generally sounds like a good compromise, if this actually helps reaching the otherwise unreachable parts of the community and have their voices heard. > Proposal 3: A decision regarding any proposal that significantly affects > backwards compatibility is within the purview of the Haskell Prime > Committee, not the Core Libraries Committee. I don't see how that would change much. The prior Haskell Prime Committee has been traditionally self-elected as well. So it's just the label of the committee you'd swap out. In the recent call of nominations[1] for Haskell Prime, the stated area of work for the new nominations was to take care of the *language* part, because that's what we are lacking the workforce for. Since its creation for the very purpose of watching over the core libraries, the core-libraries-committee has been almost exclusively busy with evaluating and deciding about changes to the `base` library and overseeing their implementation. Transferring this huge workload to the new Haskell Prime committee members who have already their hands full with revising the language part would IMO just achieve to reduce the effectiveness of the upcoming Haskell Prime committee, and therefore increase the risk of failure in producing an adequate new Haskell Report revision. Regards, H.V.Riedel [1]: https://mail.haskell.org/pipermail/haskell-prime/2015-September/003936.html [2]: https://mail.haskell.org/pipermail/haskell-cafe/2015-February/118336.html

3 4

ramin.honary@gmail.com is waiting for your reply. Respond?
by ramin.honary＠gmail.com 19 Oct '15

19 Oct '15

Hi, ramin.honary(a)gmail.com wants to follow you. ****** Is ramin.honary(a)gmail.com you friend? ****** If Yes please follow the link below: http://invites.infoaxe.net/signup_e.html?fullname=Haskell-prime+Mailing+Lis… If No please follow the link below: http://invites.infoaxe.net/signup_e.html?fullname=Haskell-prime+Mailing+Lis… Follow the link below to remove yourself from all such emails http://invites.infoaxe.net/uns_inviter.jsp?email=Haskell-prime@haskell.org&…

1 0

Re: [Haskell-cafe] Haskell ecosystem improvements meta-propsal
by Alan & Kim Zimmerman 14 Oct '15

14 Oct '15

Here is another example of a language change RFC process https://github.com/rust-lang/rfcs Alan On Wed, Oct 7, 2015 at 9:21 AM, Mike Meyer <mwm(a)mired.org> wrote: > On Wed, Oct 7, 2015 at 1:45 AM Mark Lentczner <mark.lentczner(a)gmail.com> > wrote: > >> On Tue, Oct 6, 2015 at 7:24 PM, Mike Meyer <mwm(a)mired.org> wrote: >> >>> I've dealt with the IETF RFC process and the Python PEP process, and >>> both of them worked better than that. >> >> >> While both those are good examples of mostly working organizations >> shepherding foundational technical standard(s) along... there is one thing >> more important than their processes: Their stance. Both organizations have >> a very strong engineering discipline of keeping deployed things working >> without change. I don't think it is enough to simply model their process. >> > > Well, until Python 3, anyway. > > My goal wasn't to recreate the engineering discipline that deployed things > keep working without change as you upgrade the ecosystem, it's to provide a > mechanism so the community can more easily engage with the evolution of the > ecosystem. Hopefully this will make it easier for the community to move > things forward in a desirable manner. But it's a process, and leaves the > question of whether the desire is for more stability or a less stagnant > language up to the users of the process. > > I don't necessarily want to model the IETF or PEP processes. Those are a > starting point. I tried to abstract the initial points out enough that the > final result could be either one of them, or something totally unrelated > that's a better fit for the Haskell community. > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > >

1 0

You have a new notification from ramin.honary@gmail.com. View??
by ramin.honary＠gmail.com 14 Oct '15

14 Oct '15

Hi, ramin.honary(a)gmail.com wants to follow you. ****** Is ramin.honary(a)gmail.com you friend? ****** If Yes please follow the link below: http://invites.infoaxe.net/signup_e.html?fullname=Haskell-prime+Mailing+Lis… If No please follow the link below: http://invites.infoaxe.net/signup_e.html?fullname=Haskell-prime+Mailing+Lis… Follow the link below to remove yourself from all such emails http://invites.infoaxe.net/uns_inviter.jsp?email=Haskell-prime@haskell.org&…

1 0

Self-nomination for committee
by M Farkas-Dyck 13 Oct '15

13 Oct '15

I hereby nominate myself for the Haskell Prime committee. I have been using Haskell in my personal work for about 5 years and in industry for about half a year; my experience in it includes compilers, algebra, and network servers. I feel like an ignorant child among all the potent wits in this community, but I have learnt a few rudiments of category theory. I love this language and I'm very excited to canonicalize some of the admirable work done since the last version.

1 0