October 2015 - Haskell-prime

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 10 Oct '15

10 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

Self Nomination
by Richard Eisenberg 08 Oct '15

08 Oct '15

I would like to nominate myself for the Haskell Prime committee. I have been studying Haskell intensively as I'm working toward my PhD at the University of Pennsylvania, though I started programming in Haskell only in 2011. Qualifications: * I have designed and implemented several new features in GHC: - Closed type families - Coercible/roles - Several Template Haskell improvements * I am currently putting the final touches on a large patch to GHC, merging the type and kind language and allowing reasoning about kind equalities. * My dissertation is about dependent types in Haskell/GHC. * I am currently serving as the Template Haskell czar for GHC. * I am an avid user of lots of GHC extensions, particularly those concerning types. Two of my packages -- singletons and units -- make very heavy use of type system features. Relevant opinion: * Despite my pushing the envelope in GHC, my approach toward a language standard is conservative. Specifically, I would advocate against any of GHC's growing dependent-type features to end up in the standard: we simply don't have enough experience with these! My website is at www.cis.upenn.edu/~eir if you wish to learn more about me. Thanks, Richard

1 0

Re: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`
by José Manuel Calderón Trilla 07 Oct '15

07 Oct '15

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 <greg(a)gregorycollins.net> wrote: > > On Tue, Oct 6, 2015 at 1:39 PM, Tom Ellis < > tom-lists-haskell-cafe-2013(a)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(a)gregorycollins.net> > > _______________________________________________ > Libraries mailing list > Libraries(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > >

3 3

Self nomination
by Jurriaan Hage 07 Oct '15

07 Oct '15

Dear all, I’d like to nominate myself for the Haskell Prime committee. I have been programming in Haskell since 2000 or so. Currently I teach a course on Functional Programming that discusses many of the essentials of Haskell to groups of over 240 or up. To be fair: I do not use Haskell a whole lot myself, but that is also because my work does not demand much in terms of any kind of programming, and much of other things. Master and PhD students that I supervise do typically implement their ideas in Haskell. Research-wise I have been working on Haskell too: with Bastiaan Heeren I have looked at type error diagnosis for Haskell, have contributed to the Helium compiler for novice programmers, and are currently lead maintainer of that compiler (available on Hackage). I am also involved in the Utrecht Haskell Compiler (UHC) with Atze Dijkstra, co-supervising master students working on it. I currently supervise a PhD student, Alejandro Serrano Mena, who continues the work I did with Bastiaan: domain specific type error diagnosis for Haskell 2010, with an eye to implementing this in UHC or GHC. My research interest lies in making Haskell the best vehicle for embedded domain-specific languages in the world. Incidently, I gave a talk on this at Curry On! in Prague (https://www.youtube.com/watch?v=bPrM1gONdII) Shortly, I want to extend my focus to optimisation, in a way that is transparent to the programmer. My paper on heap recycling at PEPM 2008 with Stefan Holdermans provides a sample of this. I am also much interested in the tensions that arise from combining Haskell the research-vehicle with Haskell the vehicle for the professional, and Haskell the vehicle for teaching how to program in a single specification. My website is at http://foswiki.cs.uu.nl/foswiki/Hage/WebHome where you can also find a list of publications, many of which involve Haskell one way or another. best, Jurriaan Hage Utrecht University

1 0

RE: [Haskell-cafe] MRP, 3-year-support-window, and the non-requirement of CPP (was: Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`)
by Simon Peyton Jones 07 Oct '15

07 Oct '15

I think there are several different conversations going on at once in this thread. I think it’s worth keeping them separate. · Haskell Prime. The intention there is to take a set of language features that are already in wide use in GHC (i.e. have demonstrably proved valuable), work out any dark corners, formalise them, and embody the result in a new Haskell Report. That puts a useful stake in the ground, empowers alternative implementations of Haskell, gives confidence all round. I think it’d be unusual for the Haskell Prime committee to specify a new feature of the language, one that had not been field tested. · Libraries. AMP, BBP, and Monad(return) are small but fundamental changes to the core libraries. I think there was a consensus (not universal in the case of BBP) that the change was good. Yet AMP and BBP (esp) were controversial. The issues were mostly around how to make the transition; and, given that the transition is expensive, whether the cost/benefit tradeoff justifies the change. The question of moving ‘return’ out of Monad is in this category. The Core Libraries Committee was formed explicitly to handle this stuff. So my prior assumption was that the CLC would handle the Monad(return) question, not Haskell Prime. Mark’s suggestion of a “stable” GHC 7.10 and a new GHC 8.0 is a reasonable one. But I for one would find it hard to promise to back-port every bug fix, especially as the two code bases diverge (which they will). Here is another idea. GHC knows very little about Monad. It would take work, but it probably wouldn’t be impossible to make the same GHC work with two different ‘base’ libraries, each with a different definitions of the Monad class. That would not solve the problem: you still could not use one library that used old Monad with another library that used new Monad. But at least it’d decouple it from which version of GHC you were using. I stress: it would take some work to make this go, and I’d prefer not to do this. Returning to ‘return’, my instinct is that when these pervasive breaking library changes come up, we should batch them into larger clumps. The “treadmill” complaint is real: small change A made me re-release my library; then small change B came along; and so on. Perhaps if we saved them up this would be less of an issue, for two reasons. First, the work happens once rather than many times. Second, the benefits of the change is the sum of the benefits of the little component changes, and so is more attractive to library authors and library clients. That line of thinking would suggest that the Core Libraries Committee might want to maintain a list of well-worked out agreed changes that are being “saved up” for execution at some later date. Simon From: Haskell-Cafe [mailto:haskell-cafe-bounces@haskell.org] On Behalf Of Mike Meyer Sent: 07 October 2015 00:24 To: Mark Lentczner; Johan Tibell Cc: Haskell Libraries; haskell cafe; haskell-prime(a)haskell.org List Subject: Re: [Haskell-cafe] MRP, 3-year-support-window, and the non-requirement of CPP (was: Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`) On Tue, Oct 6, 2015 at 4:15 PM Mark Lentczner <mark.lentczner(a)gmail.com<mailto:mark.lentczner@gmail.com>> wrote: On Thu, Sep 24, 2015 at 2:43 PM, Herbert Valerio Riedel <hvr(a)gnu.org<mailto:hvr@gnu.org>> wrote: TLDR: To complete the AMP, turn `Monad(return)` method into a top-level binding aliasing `Applicative(pure)`. Sure... if we had a language that no one uses and could keep reforming like putty until it is perfect. But we don't. A modest proposal: We can't keep tinkering with a language and it's libraries like this AND have a growing ecosystem that serves an ever widening base, including the range from newcomer to commercial deployment. SO - Why let's do all the language tinkering in GHC 8 there can be as many prereleases of that as needed until it is just right. ...and leave GHC 7 (7.10? roll back to 7.8.4?) for all of us doing essential and dependable libraries, commercial work, projects on Haskell that we don't want to have to go back and #ifdefs to twice a year just to keep running, educators, people writing books. We can keep improving GHC 7 as needed, and focus on bugs, security issues, patches, cross compatibility, etc. I'm just curious how much you think this would help, assuming that your solution would imply not upgrading to 8 until you're ready to. After all, you can already simply not upgrade now, and create (and distribute) fixes for bugs, security issues, cross-compatibility for 7 as you see fit. While that's a popular thing to do in lots of systems (but if we don't it. for gnus sake let's not adopt the inane parity implies stability numbering convention), it leaves two major issues unaddressed. #1, developer time. You need to get the people doing the work now to divide their efforts into the two branches.I don't know what percentage of that work is volunteer time, but I expect the answer is "most of it". If they aren't interested doing that now, what do you expect to change their mind? #2, everything else in the ecosystem. If you need updates to a library that require the branch you're not using, where does that leave you?

1 0

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

06 Oct '15

Hi, On 2015-10-06 at 21:32:19 +0200, Mikhail Glushenkov wrote: > On 6 October 2015 at 19:03, Herbert Valerio Riedel <hvr(a)gnu.org> wrote: >>> 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, [...] > > Apropos, is there a similar option for AMP warnings? I would rather > use that than CPP. Sure, added in GHC 7.8: | In GHC 7.10, Applicative will become a superclass of Monad, | potentially breaking a lot of user code. To ease this transition, GHC | now generates warnings when definitions conflict with the | Applicative-Monad Proposal (AMP). | | A warning is emitted if a type is an instance of Monad but not of | Applicative, MonadPlus but not Alternative, and when a local function | named join, <*> or pure is defined. | | The warnings are enabled by default, and can be controlled using the | new flag -f[no-]warn-amp. However, if you use that now with GHC 7.10 you get a warning: | $ ghc-7.10.2 -fno-warn-amp | | on the commandline: Warning: | -fno-warn-amp is deprecated: it has no effect, and will be removed in GHC 7.12 so you you'll need to guard that with something like if impl(ghc == 7.8.*) ghc-options: -fno-warn-amp

1 0