October 2015 - Haskell-prime

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

Re: [Haskell-cafe] Reducing the need for CPP
by Kosyrev Serge 06 Oct '15

06 Oct '15

Ben Gamari <ben(a)smart-cactus.org> writes: > 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, ... > 2. Or alternatively we could make this a idea a bit more precise, > {-# ALLOW redundant_import Prelude.(<$>) #-} ... > 3. Attach a `{-# ALLOW redundancy_import #-}` pragma to an import, > import {-# ALLOW redundant_import #-} Control.Applicative ... > 4. Attach a `{-# ALLOW redundancy_import #-}` pragma to a name in an > import list, > import Control.Applicative ((<$>) {-# ALLOW redundant_import #-}) What I don't like about this solution is how specific it is -- the gut instinct that it can't be the last such extension, if we were to start replacing CPP piecemeal. And after a while, we'd accomodate a number of such extensions.. and they would keep coming.. until it converges to a trainwreck. I think that what instead needs to be done, is this: 1. a concerted effort to summarize *all* uses of CPP in Haskell code 2. a bit of forward thinking, to include desirables that would be easy to get with a more generic solution Personally, I think that any such effort, approached with generality that would be truly satisfying, should inevitably converge to an AST-level mechanism. ..but then I remember how CPP can be used to paper over incompatible syntax changes.. Hmm.. -- с уважениeм / respectfully, Косырев Серёга

1 0

Re: Language Change Management (was: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`)
by wren romano 06 Oct '15

06 Oct '15

On Mon, Oct 5, 2015 at 5:23 PM, Adam Foltzer <acfoltzer(a)gmail.com> wrote: >> Also I'm not sure if there would be less complaints if >> AMP/FTP/MFP/MRP/etc as part of a new Haskell Report would be switched on all >> at once in e.g. `base-5.0`, breaking almost *every* single package out there >> at once. > > I doubt the number of complaints-per-change would be fewer, but I'm strongly > in favor of moving away from what feels like a treadmill that doesn't value > the time of developers and that doesn't account for the > more-than-sum-of-parts cost of the "constant flux". Broadly speaking, I'm a "fix it now rather than later" sort of person in Haskell because I've seen how long things can linger before finally getting fixed (even when everyone agrees on what the fix should be and agrees that it should be done). However, as I mentioned in the originating thread, I think that —at this point— when it comes to AMP/FTP/MFP/MRP/etc we should really aim for the haskell' committee to work out a comprehensive solution (as soon as possible), and then enact all the changes at once when switching to Haskell201X/base-5.0/whatevs. I understand the motivations for wanting things to be field-tested before making it into the report, but I don't think having a series of rapid incremental changes is the correct approach here. Because we're dealing with the Prelude and the core classes, the amount of breakage (and CPP used to paper over it) here is much higher than our usual treadmill of changes; so we should take that into account when planning how to roll the changes out. -- Live well, ~wren

2 2

Re: Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`
by Malcolm Wallace 05 Oct '15

05 Oct '15

On other social media forums, I am seeing educators who use Haskell as a vehicle for their main work, but would not consider themselves Haskell researchers, and certainly do not have the time to follow Haskell mailing lists, who are beginning to say that these kinds of annoying breakages to the language, affecting their research and teaching materials, are beginning to disincline them to continue using Haskell. They are feeling like they would be less well disposed to reviewing papers that use Haskell, and less well disposed to collaborating on writing papers that involve Haskell. Please can the Haskell Prime Committee take into account the views of such "peripheral" users of the language, who after all, form some measure of its recent "success". Haskell is a real-world tool for many people, and breakage of their code, and their sources of information about Haskell, is a powerful disincentive to continue with it. Regards, Malcolm > On 5 Oct 2015, at 10:05, Malcolm Wallace wrote: > >> I am also a strong -1 on small changes that break huge numbers of things for somewhat trivial benefits. >> >> Regards, >> Malcolm >> >> On 2 Oct 2015, at 11:09, Henrik Nilsson wrote: >> >>> Hi all, >>> >>> I have discussed the monad of no return proposal with >>> my colleague Graham Hutton: a long-standing member of >>> the Haskell community, well-known researcher, some 20 >>> years of experience of teaching Haskell to >>> undergraduate students, and author of one of the most >>> successful introductory Haskell textbooks there are. >>> >>> The upshot of this e-mail is a strong collective -2 >>> from us both on particular proposal, and a general call >>> for much more caution when it comes to breaking changes >>> that are not critically important. >>> >>> First, on a general note, there has recently been a >>> flurry of breaking changes to the (de facto) Haskell >>> standards. In many cases for very good reasons, but >>> sometimes it seems more in a quest for perfection >>> without due consideration for the consequences. It used >>> to be the case that breaking changes were very rare >>> indeed. And for good reason. >>> >>> Right now, the main "measure of breakage" in the >>> on-line discussions seems to be how many packages that >>> break in Hackage. Which of course makes sense: the >>> Hackage repository is very important and such a measure >>> is objective, as far as it goes. >>> >>> But we should not forget that breakage can go far >>> beyond Hackage. For starters, there is *lots* of code >>> that is not in Hackage, yet critically important to its >>> users, however many or few they are. There are more >>> than hundreds of thousands of copies of books out there >>> where that may break in that examples may no longer >>> work. And they cannot be changed. There are countless >>> research papers that may break in the same way. Every >>> single institution that use Haskell in their teaching >>> may have to update their teaching materials (slides, >>> code, lab instructions) for every module that teaches >>> or uses Haskell. And last but not the least, what >>> countless of programmers and students have learned >>> about Haskell over decades, most of whom are *not* >>> power users who can take these changes in their stride, >>> may also break. >>> >>> Now, of course a language has to evolve, and sometimes >>> breaking backwards compatibility is more or less >>> essential for the long-term benefit of the language. >>> But we should not let perfection be the enemy of the >>> good. >>> >>> As to this particular proposal, the monad of no return, >>> it does not seem essential to us, but mostly motivated >>> by a quest for "perfection" as defined by a very >>> knowledgeable but in relative terms small group of >>> people. >>> >>> One argument put forward was that applicative code that >>> uses "return" instead of "pure" should get a less >>> constrained type. But such code is relatively new. The >>> methods of the Monad class have been return and bind >>> for some 25 years. So indeed, as Henning Thielemann >>> wrote: why should not the newer code be adapted and use >>> "pure" instead? In fact, the use of "pure" in such code >>> could serve as a quite useful cue that the code is >>> applicative rather than monadic, especially where >>> applicative do is employed. >>> >>> Another reason put forward is support for the >>> applicative do syntax. But that is, in standard terms, >>> only a future possibility at this point. Further, the >>> syntax is arguably rather dubious anyway as it, in >>> particular to someone with an imperative background, >>> suggests a sequential reading which is exactly what >>> applicative is not and why it is useful. So from that >>> perspective, using the applicative operators directly, >>> without any syntactic sugar, actually amounts to a much >>> more transparent and honest syntax, even if a bit more >>> verbose in some cases. >>> >>> The bottom line is that it is premature to put forward >>> support for the applicative do syntax as a rationale >>> for a non-essential breaking change. >>> >>> Best regards, >>> >>> Henrik Nilsson and Graham Hutton >>> >>> -- >>> Henrik Nilsson >>> School of Computer Science >>> The University of Nottingham >>> nhn(a)cs.nott.ac.uk >> >

11 14

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

05 Oct '15

On Mon, Oct 5, 2015 at 9:02 PM, Erik Hesselink <hesselink(a)gmail.com> wrote: > On 5 October 2015 at 20:58, Sven Panne <svenpanne(a)gmail.com> wrote: > > 2015-10-05 17:09 GMT+02:00 Gershom B <gershomb(a)gmail.com>: > >> > >> [...] 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... > > Does the hack mentioned on the GHC trac [1] work for this? It seems a > bit fragile but that page says it works and it avoids CPP. > No it doesn't, if you also don't want closed import lists (which you should).

1 0

Self-nomination
by Lennart Augustsson 05 Oct '15

05 Oct '15

I would like to nominate myself to the Haskell Prime committee. About me: * I wrote the first publicly available Haskell compiler, hbc, which was available August 1990. * Subsequently I've written three more Haskell(-ish) compilers. * I've been on the Haskell Committee before. * I like experimentation with language features, but I'm very conservative about using them in production code. -- Lennart Augustsson

1 0