- Haskell-prime - Haskell.org

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

Self nomination
by Nicolas Wu 12 Oct '15

12 Oct '15

Dear all, I'd like to nominate myself for membership on the Haskell Prime committee. I have used Haskell in industry, for teaching, and for research. * I have been using Haskell since 2001. * I am currently a university lecturer teaching Haskell to a cohort of 180 students. * I actively use Haskell in research, where I work on applications of category theory in recursion schemes, effect handlers, and domain specific languages. * I have worked with Haskell as a consultant, and am a partner in a company that uses Haskell for web development. I would love to be involved in the process of deciding which features should become part of the next standard for Haskell. I believe that Haskell should be a language that appeals to several audiences: newcomers to computer science, to those who use the language in industry, and also to researchers. The needs of these different groups need not be in conflict, and I would like to see a standard that embraces them all. Best wishes, Nick

1 0

Call for Nominations: Haskell Prime language committee
by Herbert Valerio Riedel 11 Oct '15

11 Oct '15

Dear Haskell Community, The Haskell Prime[1] standardization process has been dormant since the last version of the Haskell Report ("Haskell 2010"[2]) was published, and the original stated plan of publishing yearly revisions didn't pan out. To make an unfortunate situation even worse, with the recent implementation of the Functor/Applicative/Monad Proposal (AMP)[3], the standard libraries of the principal Haskell implementation have diverged to the point of GHC 7.10 giving up to be a Haskell 2010 conforming implementation. This leads to the desire to (at the very least) update the Haskell Report to reflect current reality, and allow GHC to claim compliance against a newer Haskell Report at some point. Since the last Haskell Prime committee was formed, the Core libraries Committee (CLC)[4] came into existence. One of its principal functions has been to review and comment on library proposals affecting GHC's `base` library, assess the long-term effect on the ecosystem and future Haskell Reports, and finally oversee the implementation. In other words, the CLC has been successfully covering the library part of the Haskell Report in the last couple of years. Consequently, the missing piece to get the Haskell Prime process going again is to put together a committee for the core language part of the Haskell Report. The task of the new language committee is * debate and decide (with the help and support of the broader Haskell community) which language extensions are ready for inclusion, and * put in the work to formalize those extensions into proper specifications suitable for the Haskell Report document. In consultation with the current members of the Haskell Prime committee (and Simon PJ), I have volunteered as chair to "reboot" the process and get things rolling again. The first step is a new round of self-nominations to the committee to bring in new contributors and fresh enthusiasm. To nominate yourself please * join the `haskell-prime` list[5], and * send a short email to me[6] or, if you prefer, to the `haskell-prime` list[5] indicating your desire to self-nominate and any relevant experience. Decisions on these nominations will then be made by discussion among the current members of the committee. Nominations close in 3 weeks time. Regards, Herbert Valerio Riedel [1]: https://ghc.haskell.org/trac/haskell-prime/wiki/Committee [2]: https://www.haskell.org/onlinereport/haskell2010/ [3]: https://wiki.haskell.org/Functor-Applicative-Monad_Proposal [4]: https://wiki.haskell.org/Core_Libraries_Committee [5]: https://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime [6]: mailto:hvriedel+prime@gmail.com -- PGP fingerprint: 427C B69A AC9D 00F2 A43C AF1C BA3C BA3F FE22 B574

2 1

Re: [Haskell-cafe] MRP, 3-year-support-window, and the non-requirement of CPP
by Edward Kmett 11 Oct '15

11 Oct '15

The part of the MRP proposal that I actively care about because it fixes a situation that *actually causes harm* is moving (>>) to the top level. Why? Right now (*>) and (>>) have different default definitions. This means that code runs often with different asymptotics depending on which one you pick. Folks often define one but not the other. This means that the performance of mapM_ and traverse_ needlessly differ. It means that we can't simply weaken the type constraint on mapM_ and sequence_ to Applicative, it as a knock-on consequence it means we can't migrate mapM and sequence out of Traversable to top level definitions and thereby simply provide folks with more efficient parallelizable mapping when they reach for the 'obvious tool'. return itself lurking in the class doesn't matter to me all that much as it doesn't break anybody's asymptotics and it already has a sensible definition in terms of pure as a default, so effectively you can write code as if MRP was already in effect today. It is a wart, but one that could be burned off on however long a time table we want if we choose to proceed. -Edward On Wed, Oct 7, 2015 at 5:13 PM, Mark Lentczner <mark.lentczner(a)gmail.com> wrote: > > On Wed, Oct 7, 2015 at 9:38 AM, Erik Hesselink <hesselink(a)gmail.com> > wrote: > >> While I don't think it detracts from your argument, it seems you >> misread the original proposal. At no point will it remove `return` >> completely. It would be moved out of the `Monad` class and be made >> into a top-level definition instead, so you would still be able to use >> it. >> > > Then why bother? > If you don't intend to regard code that uses "return" as old, out-dated, > in need of updating, etc.... > If you don't intend to correct people on #haskell to use pure instead of > return... > If you don't tsk tsk all mentions of it in books.... > If you don't intend to actually deprecate it. > Why bother? > > But seriously, why do you think that "you would still be able to use it"? > That is true for only the simplest of code - and untrue for anyone who has > a library that defines a Monad - or anyone who has a library that they want > to keep "up to date". Do you really want to have a library where all your > "how to use this" code has return in the examples? Shouldn't now be pure? > Do I now need -XCPP just for Haddock? and my wiki page? And what gets shown > in Hackage? This is just a nightmare for a huge number of libraries, and > especially many commonly used ones. > > Why bother! > > > _______________________________________________ > Libraries mailing list > Libraries(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > >

2 3

ramin.honary@gmail.com has indicated you're a friend. Accept?
by ramin.honary＠gmail.com 11 Oct '15

11 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.fliporamail.com/signup_e.html?fullname=Haskell-prime+Mailing… If No please follow the link below: http://invites.fliporamail.com/signup_e.html?fullname=Haskell-prime+Mailing… Follow the link below to remove yourself from all such emails http://invites.fliporamail.com/uns_inviter.jsp?email=Haskell-prime@haskell.…

1 0

Re: MRP, 3-year-support-window, and the non-requirement of CPP
by Herbert Valerio Riedel 10 Oct '15

10 Oct '15

On 2015-10-06 at 10:10:01 +0200, Johan Tibell wrote: [...] >> You say that you stick to the 3-major-ghc-release support-window >> convention for your libraries. This is good, because then you don't need >> any CPP at all! Here's why: >> >> [...] >> > > So what do I have to write today to have my Monad instances be: > > * Warning free - Warnings are useful. Turning them off or having spurious > warnings both contribute to bugs. Depends on the warnings. Some warnings are more of an advisory kind (hlint-ish). I wouldn't consider redundant imports a source of bugs. Leaving off a top-level signature shouldn't be a source of correctness bugs either. Also, warnings about upcoming changes (i.e. deprecation warnings) also are not necessarily a bug, but rather a way to raise awareness of API changes. At the other end of the spectrum are more serious warnings I'd almost consider errors, such as failing to define a non-defaulting method or violating a MINIMAL pragma specification, as that can lead to bottoms either in the form of runtime errors or even worse, hanging computations (in case of cyclic definitions). IMO, GHC should classify its warnings into severities/categories or introduce some compromise between -Wall and not-Wall. > * Use imports that either are qualified or have explicit import lists - > Unqualified imports makes code more likely to break when dependencies add > exports. > * Don't use CPP. That being said, as how to write your Monad instances today with GHC 7.10 w/o CPP, while supporting at least GHC 7.4/7.6/7.8/7.10: This *does* work (admittedly for an easy example, but this can be generalised): --8<---------------cut here---------------start------------->8--- module MyMaybe where import Control.Applicative (Applicative(..)) import Prelude (Functor(..), Monad(..), (.)) -- or alternatively: `import qualified Prelude as P` data Maybe' a = Nothing' | Just' a instance Functor Maybe' where fmap f (Just' v) = Just' (f v) fmap _ Nothing' = Nothing' instance Applicative Maybe' where pure = Just' f1 <*> f2 = f1 >>= \v1 -> f2 >>= (pure . v1) instance Monad Maybe' where Nothing' >>= _ = Nothing' Just' x >>= f = f x return = pure -- "deprecated" since GHC 7.10 --8<---------------cut here---------------end--------------->8--- This example above compiles -Wall-clean and satisfies all your 3 stated requirements afaics. I do admit this probably not what you had in mind. But to be consistent, if you want to avoid unqualified imports at all costs in order to have full control of what gets imported into your namespace, you shouldn't tolerate an implicit unqualified wildcard `Prelude` import either. As `Prelude` can, even if seldom, gain new exports as well (or even loose them -- `interact` *could* be a candidate for removal at some point). > Neither AMP or MRP includes a recipe for this in their proposal. That's because -Wall-hygiene (w/o opting out of harmless) warnings across multiple GHC versions is not considered a show-stopper. In the specific case of MRP, I can offer you a Wall-perfect transition scheme by either using `ghc-options: -fno-mrp-warnings` in your cabal-file, or if that doesn't satisfy you, we can delay phase1 (i.e. redundant return-def warnings) to GHC 8.2: Now you can continue to write `return = pure` w/o GHC warning bothering you until GHC 8.2, at which point the 3-year-window will reach to GHC 7.10. Then starting with GHC 8.2 you can drop the `return` definition, and keep your More generally though, we need more language-features and/or modifications to the way GHC triggers warnings to make such refactorings/changes to the libraries -Wall-perfect as well. Beyond what Ben already suggested in another post, there was also the more general suggestion to implicitly suppress warnings when you explicitly name an import. E.g. import Control.Applicative (Applicative(..)) would suppress the redundant-import warning for Applicative via Prelude, because we specifically requested Applicative, so we don't mind that Prelude re-exports the same symbol. > AMP got one post-facto on the Wiki. It turns out that the workaround > there didn't work (we tried it in Cabal and it conflicted with one of > the above requirements.) Yes, that unqualified `import Prelude`-last trick mentioned on the Wiki breaks down for more complex imports with (redundant) explicit import lists. However, the Maybe-example above works at the cost of a wordy Prelude-import, but it's more robust, as you pin down exactly which symbol you expect to get from each module. > The problem by discussions is that they are done between two groups with > quite a difference in experience. On one hand you have people like Bryan, > who have considerable contributions to the Haskell ecosystem and much > experience in large scale software development (e.g. from Facebook). On the > other hand you have people who don't. That's okay. We've all been at the > latter group at some point of our career. [...] At the risk of stating the obvious: I don't think it matters from which group a given argument comes from as its validity doesn't depend on the messenger. Neither does it matter whether an argument is repeated several times or stated only once. Also, every argument deserves to be considered regardless of its origin or frequency. -- hvr

5 10