- Haskell-prime - Haskell.org

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

Self-nomination
by José Manuel Calderón Trilla 04 Oct '15

04 Oct '15

Hello everyone, I would also like to nominate myself for the Haskell committee reboot. I'm currently finishing my PhD at the University of York, just submitted last week and going to defend in the next few months. I will be starting at Galois later this month but cannot claim to speak for the company. A small group of us at York have considered writing a (new) York Haskell Compiler. One of the issues faced when considering such a project is that many people expect more than what Haskell98 or Haskell2010 offer, but many of those things are underspecified. The fallback of 'just do what GHC does' defeats the purpose in our eyes. Having a modern standard would help pin down the common extensions to Haskell2010 that people rely on while leaving room for experimentation on the 'how'. While most of my work has been on the implementation side of things, I am comfortable with the theoretical aspect of language design. Having just finished my thesis, I'm keen to start on another problem. Having a new, up-to-date, standard is something I feel is important to the wider Haskell community and I would love the opportunity to be involved. Best wishes, José Manuel

1 0

Self-nomination
by Andres Löh 04 Oct '15

04 Oct '15

Hi. I'd like to nominate myself for membership in the new Haskell Prime committee. About me: * I've been a Haskell user since 1997. * Back then, to learn Haskell, I read the entire Haskell 1.4 language report. * I have experience in programming languages theory and language design, with most of my research focusing on datatype-generic programming in Haskell (e.g. the stuff that is currently available as DeriveGeneric etc in GHC). * I have extensive experience in teaching Haskell, both in an academic and a commercial context. * I was a member of the Haskell 2010 committee. I'd like to contribute to the new standardization effort, and am very grateful to hvr for taking the lead. I believe that the current system of accumulating more and more language extensions is only sustainable in the long term if we shift the baseline from time to time. Even more than just making a decision on what a new "Haskell" could and should look like, I think that a likely benefit of the standardization process will be that we improve the documentation of extensions, reveal dark corners of underspecficiation and strange interactions, and perhaps can help to clean up certain things here and there. Cheers, Andres

2 1

A reluctant self-nomination
by Mario Blažević 25 Sep '15

25 Sep '15

I'm hereby self-nominating for the Haskell' commitee. The main reason I'm applying is because I'm afraid that the commitee might disband like the previous one. If there are enough members already, feel free to ignore my nomination. That being said, here are my qualifications: I started programming in Haskell around the turn of the century. I first published on Hackage in 2008 [1]. I have published 9 packages so far [2], 2 of which are deprecated, and I made small contributions to several other Haskell projects over the years. My projects generally use the minimal set of GHC's extensions that's necessary for the job. While I occasionally comment on Reddit and the mailing lists, I don't publicise much [3][4]. Last year I've managed to get Haskell into production at work. Outside Haskell, my job involves plenty of language maintenance and DSL design, though I wouldn't consider any of it close to the Haskell level of sophistication. In particular, I'm sorely lacking the expertise in type theory. On the other hand, I have plenty of experience in DSL support and language evolution. I can provide more details if necessary. [1] http://hackage.haskell.org/package/scc-0.1 [2] http://hackage.haskell.org/user/MarioBlazevic [3] https://themonadreader.files.wordpress.com/2011/10/issue19.pdf [4] https://github.com/blamario/monoid-subclasses/wiki/Files/HaskellSymposium20…

1 0

Self-nomination
by wren romano 23 Sep '15

23 Sep '15

Hello, I'd like to nominate myself for the new Haskell Prime committee. Experience-wise: I've been active on the libraries list for something like a decade. A couple years ago I wrote my "burning bridges" email[1], observing that we've long known certain problems with official/standard Haskell, and equally long known the solutions, but had been unwilling to actually push through the communally agreed upon solutions. That email in turn spawned the AMP[2] and the FTP[3]. The AMP has been widely praised as an improvement. The FTP has been more controversial (since it was less thoroughly thought through), but is still I think widely viewed in a positive light. One thing I'd like to see/work on is fully integrating these proposals into the standard, so that we can knock off the rough edges (esp. re the FTP, as we've discovered numerous oversights in how that's been implemented so far) and make things easier and more polished for the other Haskell compilers like JHC and UHC to work with. Outside of Haskell per se, my work focuses on formalizing language semantics. Some examples include my master's work on typed unification in the weighted-logic programming language Dyna[4], my thesis work on chiastic lambda-calculi[5] including mechanized proofs in Coq, and my current work on the probabilistic programming language Hakaru[6]. I also helped Lindsey and Ryan work out the semantic underpinnings of LVars[7], though this isn't documented anywhere. [1] <https://mail.haskell.org/pipermail/libraries/2013-May/019902.html> [2] <https://wiki.haskell.org/Functor-Applicative-Monad_Proposal> [3] <https://ghc.haskell.org/trac/ghc/ticket/9586> [4] I just found out Wes made a github repo <https://github.com/nwf/dyna> for Dyna2 (the reimplementation of Dyna1 we worked on together), though I haven't checked to see whether my typed unification stuff is in there yet. [5] <http://cl.indiana.edu/~wren/pubs/chiastic_nlcs2013.pdf> [6] <https://github.com/hakaru-dev/hakaru> [7] <http://www.cs.indiana.edu/~lkuper/papers/lindsey-kuper-dissertation.pdf> -- Live well, ~wren

1 0

David/quchen nomination
by David Luposchainsky 23 Sep '15

23 Sep '15

Hello *, I'd like to throw my hat in for the committee. Some of you might know me from the proposal texts of the AMP and now the MFP; I've been an active Haskell and #haskell user for a couple of years now (although mostly for private projects library-wise), and during that time I think I've stumbled upon enough design decision explanations, nifty semantical questions, and interesting problems to be ready for the Haskell Prime process. I'm now used to my new job so I have a pretty good idea about how much spare time I have; and since it's going to start snowing in the Alps soon, I think my bike is going to be a clear #2 to Haskell in terms of things I like to do. Greetings, David/quchen

1 0