- Haskell-prime - Haskell.org

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

Re: Reducing the need for CPP (was: Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`)
by Johan Tibell 06 Oct '15

06 Oct '15

It might be enough to just add a NOWARN <warning type> pragma that acts on a single line/expression. I've seen it in both C++ and Python linters and it works reasonably well and it's quite general. On Tue, Oct 6, 2015 at 10:44 AM, Ben Gamari <ben(a)smart-cactus.org> wrote: > Sven Panne <svenpanne(a)gmail.com> writes: > > > 2015-10-05 17:09 GMT+02:00 Gershom B <gershomb(a)gmail.com>: > > > >> On October 5, 2015 at 10:59:35 AM, Bryan O'Sullivan (bos(a)serpentine.com > ) > >> wrote: > >> [...] As for libraries, it has been pointed out, I believe, that without > >> CPP one can write instances compatible with AMP, and also with AMP + > MRP. > >> One can also write code, sans CPP, compatible with pre- and post- AMP. > [...] > >> > > > > Nope, at least not if you care about -Wall: If you take e.g. (<$>) which > is > > now part of the Prelude, you can't simply import some compatibility > module, > > because GHC might tell you (rightfully) that that import is redundant, > > because (<$>) is already visible through the Prelude. So you'll have to > use > > CPP to avoid that import on base >= 4.8, be it from it Data.Functor, > > Control.Applicative or some compat-* module. And you'll have to use CPP > in > > each and every module using <$> then, unless I miss something obvious. > > AFAICT all transitioning guides ignore -Wall and friends... > > > This is a fair point that comes up fairly often. The fact that CPP is > required to silence redundant import warnings is quite unfortunate. > Others languages have better stories in this area. One example is Rust, > which has a quite flexible `#[allow(...)]` pragma which can be used to > acknowledge and silence a wide variety of warnings and lints [1]. > > I can think of a few ways (some better than others) how we might > introduce a similar idea for import redundancy checks in Haskell, > > 1. Attach a `{-# ALLOW redundant_import #-}` pragma to a definition, > > -- in Control.Applicative > {-# ALLOW redundant_import (<$>) #-} > (<$>) :: (a -> b) -> f a -> f b > (<$>) = fmap > > asking the compiler to pretend that any import of the symbol did not > exist when looking for redundant imports. This would allow library > authors to appropriately mark definitions when they are moved, > saving downstream users from having to make any change whatsoever. > > 2. Or alternatively we could make this a idea a bit more precise, > > -- in Control.Applicative > {-# ALLOW redundant_import Prelude.(<$>) #-} > (<$>) :: (a -> b) -> f a -> f b > (<$>) = fmap > > Which would ignore imports of `Control.Applicative.(<$>)` only if > `Prelude.(<$>)` were also in scope. > > 3. Attach a `{-# ALLOW redundancy_import #-}` pragma to an import, > > import {-# ALLOW redundant_import #-} Control.Applicative > > -- or perhaps > import Control.Applicative > {-# ALLOW redundant_import Control.Applicative #-} > > allowing the user to explicitly state that they are aware that this > import may be redundant. > > 4. Attach a `{-# ALLOW redundancy_import #-}` pragma to a name in an > import list, > > import Control.Applicative ((<$>) {-# ALLOW redundant_import #-}) > > allowing the user to explicitly state that they are aware that this > imported function may be redundant. > > In general I'd like to reiterate that many of the comments in this > thread describe genuine sharp edges in our language which have presented > a real cost in developer time during the AMP and and FTP transitions. I > think it is worth thinking of ways to soften these edges; we may be > surprised how easy it is to fix some of them. > > - Ben > > > [1] https://doc.rust-lang.org/stable/reference.html#lint-check-attributes > > _______________________________________________ > Libraries mailing list > Libraries(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > >

2 1

Re: MRP, 3-year-support-window, and the non-requirement of CPP (was: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`)
by Johan Tibell 06 Oct '15

06 Oct '15

(Resending with smaller recipient list to avoid getting stuck in the moderator queue.) On Tue, Oct 6, 2015 at 9:10 AM, Herbert Valerio Riedel <hvr(a)gnu.org> wrote: > On 2015-10-05 at 21:01:16 +0200, Johan Tibell wrote: > > On the libraries I maintain and have a copy of on my computer right now: > 329 > > > Although this was already pointed out to you in a response to a Tweet of > yours, I'd like to expand on this here to clarify: > > > 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. * 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. Neither AMP or MRP includes a recipe for this in their proposal. 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.) PS: I'm a bit disappointed you seem to dismiss this proposal right away > categorically without giving us a chance to address your > concerns. The proposal is not a rigid all-or-nothing thing that > can't be tweaked and revised. That's why we're having these > proposal-discussions in the first place (rather than doing blind > +1/-1 polls), so we can hear everyone out and try to maximise the > agreement (even if we will never reach 100% consensus on any > proposal). > > So please, keep on discussing! > 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. What's frustrating is that people don't take a step bad and realize that they might be in the latter group and should perhaps listen to those in the former. This doesn't happen, instead we get lots of "C++ and Java so bad and we don't want to be like them." Haskell is not at risk of becoming C++ or Java (which are a large improvement compared to the languages came before them). We're at risk of missing our window of opportunity. I think that would be a shame, as I think Haskell is a step forward compared to those languages and I would like to see more software that used be written in Haskell. We've been through this many times before on the libraries list. I'm not going to win an argument on this mailing list. Between maintaining libraries you all use and managing a largish team at Google, I don't have much time for a discussion which approaches a hundred emails and is won by virtue of having lots of time to write emails. -- Johan

2 1

Re: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`
by Herbert Valerio Riedel 06 Oct '15

06 Oct '15

On 2015-10-06 at 14:06:11 +0200, Erik Hesselink wrote: > I was always under the impression that +1/-1 was just a quick > indicator of opinion, not a vote, and that it was the core libraries > committee that would make the final call if enough consensus was > reached to enact the change. I'd like to point out, that the core libraries committee ought to continue to do so (as hinted at in [1]) in its function as a Haskell Prime sub-Committee (c.f. sub-teams in the Rust community[2]). While there will be surely overlap of interests, contributions, cross-reviewing and discussion, the principal task and responsibility of the new sought members is to concentrate on the language part of the Haskell Report where quite a bit of work is awaiting them. Cheers, hvr [1]: https://mail.haskell.org/pipermail/haskell-prime/2015-September/003936.html [2]: https://www.rust-lang.org/team.html

1 0

Re: Reducing the need for CPP (was: Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`)
by Jan-Willem Maessen 06 Oct '15

06 Oct '15

On Tue, Oct 6, 2015 at 4:44 AM, Ben Gamari <ben(a)smart-cactus.org> wrote: > Sven Panne <svenpanne(a)gmail.com> writes: > > > 2015-10-05 17:09 GMT+02:00 Gershom B <gershomb(a)gmail.com>: > > > >> On October 5, 2015 at 10:59:35 AM, Bryan O'Sullivan (bos(a)serpentine.com > ) > >> wrote: > >> [...] As for libraries, it has been pointed out, I believe, that without > >> CPP one can write instances compatible with AMP, and also with AMP + > MRP. > >> One can also write code, sans CPP, compatible with pre- and post- AMP. > [...] > >> > > > > Nope, at least not if you care about -Wall: If you take e.g. (<$>) which > is > > now part of the Prelude, you can't simply import some compatibility > module, > > because GHC might tell you (rightfully) that that import is redundant, > > because (<$>) is already visible through the Prelude. So you'll have to > use > > CPP to avoid that import on base >= 4.8, be it from it Data.Functor, > > Control.Applicative or some compat-* module. And you'll have to use CPP > in > > each and every module using <$> then, unless I miss something obvious. > > AFAICT all transitioning guides ignore -Wall and friends... > > > This is a fair point that comes up fairly often. The fact that CPP is > required to silence redundant import warnings is quite unfortunate. > Others languages have better stories in this area. One example is Rust, > which has a quite flexible `#[allow(...)]` pragma which can be used to > acknowledge and silence a wide variety of warnings and lints [1]. > > I can think of a few ways (some better than others) how we might > introduce a similar idea for import redundancy checks in Haskell, > > 1. Attach a `{-# ALLOW redundant_import #-}` pragma to a definition, > > -- in Control.Applicative > {-# ALLOW redundant_import (<$>) #-} > (<$>) :: (a -> b) -> f a -> f b > (<$>) = fmap > > asking the compiler to pretend that any import of the symbol did not > exist when looking for redundant imports. This would allow library > authors to appropriately mark definitions when they are moved, > saving downstream users from having to make any change whatsoever. > > 2. Or alternatively we could make this a idea a bit more precise, > > -- in Control.Applicative > {-# ALLOW redundant_import Prelude.(<$>) #-} > (<$>) :: (a -> b) -> f a -> f b > (<$>) = fmap > > Which would ignore imports of `Control.Applicative.(<$>)` only if > `Prelude.(<$>)` were also in scope. > One obvious solution I haven't seen mentioned is the ability to add nonexistent identifier to a hiding clause (these identifiers might presumably exist in some other version of the import): import Prelude hiding ((<$>)) I can see the argument for marking such imports with a pragma, though it gets a bit ugly. -Jan-Willem Maessen

1 0

Re: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`
by Johan Tibell 06 Oct '15

06 Oct '15

On Mon, Oct 5, 2015 at 8:34 PM, Gregory Collins <greg(a)gregorycollins.net> wrote: > > On Mon, Oct 5, 2015 at 8:09 AM, Gershom B <gershomb(a)gmail.com> wrote: > >> My understanding of the argument here, which seems to make sense to me, >> is that the AMP already introduced a significant breaking change with >> regards to monads. Books and lecture notes have already not caught up to >> this, by and large. Hence, by introducing a further change, which >> _completes_ the general AMP project, then by the time books and lecture >> notes are all updated, they will be able to tell a much nicer story than >> the current one? > > > This is a multi-year, "boil the ocean"-style project, affecting literally > every Haskell user, and the end result after all of this labor is going to > be... a slightly spiffier bike shed? > > Strongly -1 from me also. My experience over the last couple of years is > that every GHC release breaks my libraries in annoying ways that require > CPP to fix: > > ~/personal/src/snap λ find . -name '*.hs' | xargs egrep > '#if.*(MIN_VERSION)|(GLASGOW_HASKELL)' | wc -l > 64 > > > As a user this is another bikeshedding change that is not going to benefit > me at all. Maintaining a Haskell library can be an exasperating exercise of > running on a treadmill to keep up with busywork caused by changes to the > core language and libraries. My feeling is starting to become that the > libraries committee is doing as much (if not more) to *cause* problems > and work for me than it is doing to improve the common infrastructure. > On the libraries I maintain and have a copy of on my computer right now: 329

4 3