Re: [Haskell] The Haskell Report: who maintains it?
All of us on the Haskell Language Committee have the ability to commit on that repo. I think typos are uncontroversial and I'll happily merge pull requests like that. I think the pull-request you point out suffered from the bystander effect, unfortunately. I'll review and merge it now. If you let me know the typo you'd like fixed I'll make sure that gets done as well. Cheers,José Manuel On Thu, Mar 15, 2018, at 6:52 PM, Simon Peyton Jones via Haskell wrote:> Friends > > Does anyone know who, if anyone, feels responsible for committing > updates to the Haskell 2010 Report?> > Who even has commit rights? > > There’s Frank’s pull request below, and I have another important > typo to fix.> > Thanks > > Simon > > > *From:* Frank Steffahn [mailto:notificati...@github.com] *Sent:* 11 > March 2018 17:03 *To:* haskell/haskell-report rep...@noreply.github.com> *Cc:* Subscribed > *Subject:* [haskell/haskell-report] > Fix a typo in: Semantics of Case Expressions, Part 3 (s) (#4)> > Hi. I noticed this in the Haskell 2010 report, which is an obvious > typo / mistake. I’m not 100% sure if this is the right branch (or > even in general the right place) to note this, but I hope it will get > fixed ;-)> This seems like it is an artifact of copy-and-pasting from > “Semantics > of Case Expressions, Part 1 (c)” without properly adapting the thing, > especially in commit bc94554.> > You can view, comment on, or merge this pull request online at: > https://github.com/haskell/haskell-report/pull/4[1] > Commit Summary > * Fix a typo in: Semantics of Case Expressions, Part 3 (s)> File Changes > * *M* report/exps.verb[2] (1) > Patch Links: > * https://github.com/haskell/haskell-report/pull/4.patch[3] > * https://github.com/haskell/haskell-report/pull/4.diff[4]> — You are > receiving this because you are subscribed to this thread. > Reply to this email directly, view it on GitHub[5], or mute the > thread[6].> _ > Haskell mailing list > hask...@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell Links: 1. https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fhaskell%2Fhaskell-report%2Fpull%2F4&data=04%7C01%7Csimonpj%40microsoft.com%7C31eff0e0f0104cb0e64408d58771f2eb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636563845832254992%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwifQ%3D%3D%7C-1&sdata=1xk6eQn%2Fq4vKglbQSLHNOGYrNdxJBp074b2%2ByJbvCrQ%3D&reserved=0 2. https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fhaskell%2Fhaskell-report%2Fpull%2F4%2Ffiles%23diff-0&data=04%7C01%7Csimonpj%40microsoft.com%7C31eff0e0f0104cb0e64408d58771f2eb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636563845832254992%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwifQ%3D%3D%7C-1&sdata=OYptlGmxyWflETFlpd4f8ln1AEYgT8EwiYX44dPafJI%3D&reserved=0 3. https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fhaskell%2Fhaskell-report%2Fpull%2F4.patch&data=04%7C01%7Csimonpj%40microsoft.com%7C31eff0e0f0104cb0e64408d58771f2eb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636563845832254992%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwifQ%3D%3D%7C-1&sdata=gUICTD38nmiLSOheLW14zHM%2FTj2Uv59k7kxyxXKXgpU%3D&reserved=0 4. https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fhaskell%2Fhaskell-report%2Fpull%2F4.diff&data=04%7C01%7Csimonpj%40microsoft.com%7C31eff0e0f0104cb0e64408d58771f2eb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636563845832254992%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwifQ%3D%3D%7C-1&sdata=NrCOwM0rJ8rH0p7d3tSG7YCsVziBJGli%2BKfx8SaFgDE%3D&reserved=0 5. https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fhaskell%2Fhaskell-report%2Fpull%2F4&data=04%7C01%7Csimonpj%40microsoft.com%7C31eff0e0f0104cb0e64408d58771f2eb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636563845832254992%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwifQ%3D%3D%7C-1&sdata=1xk6eQn%2Fq4vKglbQSLHNOGYrNdxJBp074b2%2ByJbvCrQ%3D&reserved=0 6. https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAAjsewyB3mgR1zjDxYvon2hz67U0hf_Zks5tdVjEgaJpZM4SlxDs&data=04%7C01%7Csimonpj%40microsoft.com%7C31eff0e0f0104cb0e64408d58771f2eb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636563845832254992%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwifQ%3D%3D%7C-1&sdata=mnTU7w1yzqPGoT6eYBrw21SvvrnH6byxUEi2yZZ1ftE%3D&reserved=0 ___ Haskell-prime mailing list Haskell-prime@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
Re: Default module header `module Main where`
Agreed, this sounds sensible. Can anyone think of any unintended consequences? -Jose On Tue, May 16, 2017, at 09:50 AM, Iavor Diatchki wrote: > That seems fairly reasonable to me. > > -Iavor > > On Tue, May 16, 2017 at 7:18 AM, Joachim Breitner breitner.de> wrote:>> Hi, >> >> a very small proposal to be considered for Haskell': >> >> Currently, the report states >> >> An abbreviated form of module, consisting only of the module >> body,>> is permitted. If this is used, the header is assumed to be >> ‘module>> Main(main) where’. >> >> I propose to change that to >> >> An abbreviated form of module, consisting only of the module >> body,>> is permitted. If this is used, the header is assumed to be >> ‘module>> Main where’. >> >> The rationale is that a main-less main module is still useful, e.g.>> when >> you are working a lot in GHCi, and offload a few >> extensions to a>> separate file. Currently, tools like hdevtools will >> complain about a>> missing main function when editing such a file. >> >> It would also work better with GHC’s -main-is flag, and avoid >> problems>> like the one described in >> https://ghc.haskell.org/trac/ghc/ticket/13704>> >> >> I don’t see any downsides. When compiling to a binary, >> implementations>> are still able to detect that a Main module is not >> imported by any >> other module and only the main function is used, and optimize as if>> only >> main were exported. >> >> Greetings, >> Joachim >> >> >> >> -- >> Joachim “nomeata” Breitner m...@joachim-breitner.de • >> https://www.joachim-breitner.de/ XMPP: nome...@joachim-breitner.de >> • OpenPGP-Key: 0xF0FBF51F Debian Developer: nome...@debian.org>> >> ___ >> Haskell-prime mailing list >> Haskell-prime@haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime >> > _ > Haskell-prime mailing list > Haskell-prime@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime ___ Haskell-prime mailing list Haskell-prime@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
Re: Meet up at ICFP?
Hello again, Thanks for everyone that emailed me with their constraints, and those that let me know they can't make it but they have specific concerns, I'll make sure those are heard. Luckily from a constraint point of view people seem pretty flexible. Richard Eisenberg suggest that lunch on Monday might be a good time. Are people okay with that? I can reach out to the local organisers to see if they can set aside a table/space for those of us that want to meet. Lunch seems like a good idea as that leaves the evenings open for impromptu plans that tend to come up at ICFP. Another time that works for everyone is Wednesday evening. I'm happy to sort something out if that's what people prefer. For now let's plan on Monday lunch and if there's a big conflict we're change course. Richard has also volunteered to act as secretary for the meeting so that the minutes of the meeting can be posted. Thanks Richard! Thanks everyone, Jose On Tue, Sep 6, 2016 at 8:08 PM, José Manuel Calderón Trilla wrote: > Hello Haskell Prime, > > On IRC Andres Löh suggested that we have a haskell prime gathering > that coincides with ICFP. I told him that I'd take on organizing it, > and now that we're only a few weeks away it's probably time to do so. > > First and foremost, the main purpose of this would be to meet each > other, put faces to names, and get a sense of who is interested in > what. We aren't trying to finalise any decisions via back-room > discussions :) > > So with that in mind, if you're interested, please email me with your > availability. Non-committee members are welcome to email me as well. > I'll find the time that works for most and sort something out. > > There are a few ICFP-wide constraints: > > Monday Sept. 19th, 18:30 - 20:30: Welcome reception and > student-research competition > Tuesday Sept. 20th, 19:00 -21:00: Reception and Banquet > Thursday Sept. 22nd, 18:30 - 20:30: Industrial Reception > > If there are any other constraints that you know of (PC meetings, > Steering Committee meetings, etc) let me know. > > Cheers, > > José ___ Haskell-prime mailing list Haskell-prime@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
Meet up at ICFP?
Hello Haskell Prime, On IRC Andres Löh suggested that we have a haskell prime gathering that coincides with ICFP. I told him that I'd take on organizing it, and now that we're only a few weeks away it's probably time to do so. First and foremost, the main purpose of this would be to meet each other, put faces to names, and get a sense of who is interested in what. We aren't trying to finalise any decisions via back-room discussions :) So with that in mind, if you're interested, please email me with your availability. Non-committee members are welcome to email me as well. I'll find the time that works for most and sort something out. There are a few ICFP-wide constraints: Monday Sept. 19th, 18:30 - 20:30: Welcome reception and student-research competition Tuesday Sept. 20th, 19:00 -21:00: Reception and Banquet Thursday Sept. 22nd, 18:30 - 20:30: Industrial Reception If there are any other constraints that you know of (PC meetings, Steering Committee meetings, etc) let me know. Cheers, José ___ Haskell-prime mailing list Haskell-prime@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
Re: Anything happening?
Hello Michael, We were waiting on the GHC team to settle on a proposal process for their stuff so that we could aim to use a similar process and avoid fragmentation. For those who don't know, GHC HQ just announced their new process here: https://ghc.haskell.org/trac/ghc/blog/rethinking-proposals and are finalising it on the github repo here: https://github.com/ghc-proposals/ghc-proposals So pretty soon now we should probably discuss whether we are going to use the same process, alter their process, or use a different process altogether. My vote would be to mirror their process as much as possible. Cheers, José On Tue, Jul 19, 2016 at 2:08 PM, Michael Walker wrote: > Hello, > > I haven't seen anything on this mailing list for a little while, is > anything going on? Has the process by which proposals will be > submitted and worked out been solidified yet? > > -- > Michael Walker (http://www.barrucadu.co.uk) > ___ > Haskell-prime mailing list > Haskell-prime@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime ___ Haskell-prime mailing list Haskell-prime@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
Re: Starting point for new standard?
Hello Christian, On Wed, May 4, 2016 at 5:35 AM, Christian Siefkes wrote: > Hi all, > > out of curiosity, what'll be the starting point for the next Haskell report? > I suppose Haskell 2010 plus the additional "No Datatype Contexts" change > accepted by the old Haskell Language committee in early 2011 (see > https://wiki.haskell.org/Haskell_2010#Additional_change )? It hasn't been stated explicitly, but I would expect you're mostly correct. The library portion of the standard is now under the purview of the Core Libraries Committee (CLC) [1]. Therefore the current Haskell Standard takes into account their work in addition to what you've mentioned. There's another thread on the mailing list about which extensions deserve to be promoted to language features which might interest you, but as far as I'm aware the assumed foundation is the 2010 report and the work of the CLC. Cheers, Jose [1]: https://wiki.haskell.org/Core_Libraries_Committee ___ Haskell-prime mailing list Haskell-prime@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
Re: Evaluation order control between two expressions
On Sat, Apr 30, 2016 at 6:11 AM, Lennart Augustsson wrote: > Order of evaluation can be very important for memory use. So I can imagine > cases where seq would run out of memory, but pseq would not. > That's fair enough. Do you think it's worth attempting to standardize the behavior of `seq` to be like `pseq`? > I would argue that pseq is almost always what you want, but seq has a nicer > denotational semantics. Is this the reason it wasn't standardized this way to begin with? Miranda's `seq` is like `pseq` (as was `seq` in other lazy language implementations) so it's not as if there wasn't precedent. ___ Haskell-prime mailing list Haskell-prime@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
Re: Chairship / responsibility
On Sat, Apr 30, 2016 at 4:03 PM, John Wiegley wrote: >> Henrik Nilsson writes: > >>> It was my understanding that Herbert would be the chair when I asked to be >>> on the committee, and the fact that this question was already answer was a >>> factor in my decision to try to help. > >> I agree completely with this. > > I also agree, and offer my thanks to Herbert for being willing to take up this > role from the beginning. Same here. ___ Haskell-prime mailing list Haskell-prime@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
Re: Evaluation order control between two expressions
Hello Takenobu, Great question, this is actually a pretty interesting issue! It isn't out of scope at all. The first thing to think about is the following thought experiment: Without the presence of side-effects, how can you tell the difference between a `seq` that conforms to the Haskell report and one that evaluates it's first argument before its second? If your answer involves `unsafePerformIO` then you're cheating ;) Even if your first argument to `seq` is an IO action it won't get executed because `seq` only evaluates to WHNF. It might be possible to construct a program that allows you to observe the difference, but in the general case I don't see how you could. I'd be very interested to be shown otherwise though! Now in a parallel program things change. When we use `pseq` it's because we don't want two threads to collide when trying to evaluate the same expression. Let's look at an example: x `par` y `seq` x + y As you noted, the semantics of `seq` doesn't actually guarantee that `y` will be evaluated before `x + y`. But this only matters because we've used `par` and introduced threads (via an effect!) and therefore the possibility of collision. We can avoid this by using `pseq` instead. So, both `seq` and `pseq` both allow the programmer to express *operational* concerns, `seq` is used mostly to eliminate/manage space leaks, and `pseq` is used to specify order of evaluation. Those concerns sometimes overlap, but they are different! It could be argued (and I would agree) that `seq` is a bad name; a better name might have been something like `synch` [1]. That being said, unless we add parallelism to the standard (and even then) I am not sure it would be wise to change the operational behavior of `seq`. It's current behavior is well established, and if you're writing sequential Haskell code where order of evaluation matters, it's probably better to reach for a different tool (IMO). However, if parallelism is introduced then I'd fight for `pseq` to be part of that (as you suggest). I hope that sheds some light on the issue. Cheers, Jose [1]: John Hughes introduced a `synch` combinator in his thesis, but it had very different semantics, so maybe that's a reason it was avoided? Someone with more knowledge of the history can probably shed more light on this. On Thu, Apr 28, 2016 at 6:56 PM, Takenobu Tani wrote: > Dear Community, > > Apologies if I'm missing context. > > Does Haskell 2020 specify evaluation order control by `pseq`? > > We use `pseq` to guarantee the evaluation order between two expressions. > But Haskell 2010 did not specify how to control the evaluation order between > two expressions. > (only specified `seq` in Haskell 2010 section 6.2 [1]. but `seq` don't > guarantee the order. [2]) > > I think it's better to explicitly specify `pseq` as standard way. > > Already discussed? or out of scope? > > [1]: > https://www.haskell.org/onlinereport/haskell2010/haskellch6.html#x13-1260006.2 > [2]: > https://www.schoolofhaskell.com/user/snoyberg/general-haskell/advanced/evaluation-order-and-state-tokens > > Regards, > Takenobu > > > ___ > Haskell-prime mailing list > Haskell-prime@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime > ___ Haskell-prime mailing list Haskell-prime@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
Re: Infrastructure & Communication
Hello, First of all, thanks for all your effort in setting this up! On Thu, Apr 28, 2016 at 5:56 PM, Herbert Valerio Riedel wrote: > > However, since Trac has accumulated quite a bit of old content in its > ticket-tracker over the years, and "Haskell 2020" has been coined a > reboot. Maybe it wouldn't be such a bad idea to start over at GitHub, > and consider the Trac instance mostly as a legacy archive of historic > content. > > > GitHub allows for Git-based workflows, and there's prior art related to > language design we could steal ideas from, for instance: > > - https://github.com/fsharp/FSharpLangDesign > - https://github.com/rust-lang/rfcs > - https://github.com/golang/proposal > - (any others noteworthy?) > This seems like the pragmatic way forward. And, as you say, there's plenty of evidence from other language communities that it can work effectively. > IMO, GitHub's issue tracker has become flexible enough for our needs and > its integration with Git pull-requests allows to e.g. group together > change proposal description/motivation, discussion, and finaly the delta > to the haskell-report (with inline annotations/reviews) and so on. > (However, I consider GitHub's Wiki-component quite weak. I'm not sure > what to do about that. Maybe keep using Trac's wiki for that?) > I personally have no problem with a Trac wiki. That being said, the Rust model of having an RFC repo seems to have worked really well for them and allows for easy discussion and comments from the community at large. If we choose to go that route I would gladly take the time to gather relevant info from the Trac wiki and organize it similarly to the way the Rust team has. > Does anyone object to using GitHub? > I think it's great. > In case there's no objection, which of the existing language-design > GitHub projects do you consider a good fit for Haskell Prime and > therefore worthy of imitation? > I'm a big fan of the Rust model myself. Thanks again for your effort in getting all this off the ground, Jose ___ Haskell-prime mailing list Haskell-prime@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
Re: Haskell Prime 2020 committee
There seems to be a minimum of 5 characters for a username, which was giving me the “Username doesn't match local naming policy.” error. I was able to make an account with a longer username, but I am not able to edit the wiki. Unsure if it's some sort of anti-spam delay or some other issue with permissions. -Jose On Thu, Apr 28, 2016 at 5:13 PM, wren romano wrote: > On Thu, Apr 28, 2016 at 2:24 PM, Antonio Nikishaev wrote: >>> On 28 Apr 2016, at 21:45, Richard Eisenberg wrote: >>> Seems reasonable. I have started the page at >>> https://wiki.haskell.org/Language/HaskellPrime >> >> Should it be under prime.haskell.org instead? >> >> (I don't seem to be able to register there though, “Username doesn't match >> local naming policy.”) > > The idea seems reasonable, but I also can't set up an account on the wiki... > > > -- > Live well, > ~wren > ___ > Haskell-prime mailing list > Haskell-prime@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime ___ Haskell-prime mailing list Haskell-prime@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
Re: Update on Haskell Prime reboot?
Hi Richard, > As a concrete suggestion, I wonder if we should have two goals: > > 1. Write down an updated standard for Haskell. > > 2. Write down pre-standards for several extensions. I agree with both of these. It may even be useful to use goal 2 as a stepping stone to determine what extensions should receive the extra attention necessary (if any) to be part of goal 1. Were you thinking that these pre-standards would look something like Mark Jones's 'Typing Haskell in Haskell' paper? A simplified and clear specification in the form of a Haskell program would go a long way in clarifying the meaning of certain extensions. To use your example, you could imagine an implementation of GADTs that forms the baseline of what the GADT extension should mean (implementations should accept at least what this one does). That might be too ambitious though. A lot of the 'obvious' extensions were discussed that last time the Haskell Prime committee was active, so a lot of groundwork has been laid already. The most important step right now is empowering people to move forward with the process. Herbert Valerio Riedel is the chair of the reboot, and as such gets final say on who is a member of the committee and any timeline for deciding. That being said, I think the aim should be to have the committee membership decided soon and start discussing what the priorities should be. I'm partial to suggesting a face to face meeting at ICFP, but realize that it is difficult for many to attend to ICFP. Cheers, José On Fri, Apr 22, 2016 at 9:33 AM, Richard Eisenberg wrote: > I stand by ready to debate standards and would enjoy moving this process > forward. However, I'm not in a position where I can lead at the moment -- > just too consumed by other tasks right now. > > As a concrete suggestion, I wonder if we should have two goals: > > 1. Write down an updated standard for Haskell. > > 2. Write down pre-standards for several extensions. > > About (2): I'm very sympathetic to a recent post on Haskell-cafe about having > formal descriptions of language extensions. It is not our purview to document > GHC. However, several extensions are in very common use, but might not be > quite ready for a language standard. Chief among these, in my opinion, is > GADTs. GADTs are problematic from a standardization standpoint because it's > quite hard to specify when a GADT pattern-match type-checks, without > resorting to discussion of unification variables. For this reason, I would be > hesitant about putting GADTs in a standard. On the other hand, it shouldn't > be too hard to specify some sort of minimum implementation that individual > compilers can build on. I'm calling such a description a "pre-standard". > > Thoughts? > > Richard > > On Apr 21, 2016, at 5:22 PM, José Manuel Calderón Trilla wrote: > >> Hello all, >> >> I'm curious if there is any progress on the reboot of the Haskell >> Prime committee. It has been six months since the closing of >> nominations and there hasn't been any word that I'm aware of. I've >> also spoken to a few others that have self-nominated and they too have >> not heard any news. >> >> Personally, I feel that a new standard is very important for the >> future health of the community. Several threads on the mailing list >> and posts on the web, such as one on reddit today [1], show a desire >> from the community for a major consolidation effort. >> >> If there is any way that I can help the process along I would be glad >> to do so. It would be a shame to allow for the enthusiasm for a new >> committee fade away. >> >> Cheers, >> >> José >> >> >> [1]: >> https://www.reddit.com/r/haskell/comments/4fsuvu/can_we_have_xhaskell2016_which_turns_on_the_most/ >> ___ >> Haskell-prime mailing list >> Haskell-prime@haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime >> > ___ Haskell-prime mailing list Haskell-prime@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
Update on Haskell Prime reboot?
Hello all, I'm curious if there is any progress on the reboot of the Haskell Prime committee. It has been six months since the closing of nominations and there hasn't been any word that I'm aware of. I've also spoken to a few others that have self-nominated and they too have not heard any news. Personally, I feel that a new standard is very important for the future health of the community. Several threads on the mailing list and posts on the web, such as one on reddit today [1], show a desire from the community for a major consolidation effort. If there is any way that I can help the process along I would be glad to do so. It would be a shame to allow for the enthusiasm for a new committee fade away. Cheers, José [1]: https://www.reddit.com/r/haskell/comments/4fsuvu/can_we_have_xhaskell2016_which_turns_on_the_most/ ___ Haskell-prime mailing list Haskell-prime@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
Re: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`
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 wrote: > > On Tue, Oct 6, 2015 at 1:39 PM, Tom Ellis < > tom-lists-haskell-cafe-2...@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 > > ___ > Libraries mailing list > librar...@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > ___ Haskell-prime mailing list Haskell-prime@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
Self-nomination
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 ___ Haskell-prime mailing list Haskell-prime@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
