Heads up on mailing list stability
Hi all! We're incrementally transitioning some of our mail sending to a new server. This list is one of the first being migrated to be relayed through the new server (we're also moving the ghc steering-committee list). If sending or receiving is dodgier than usual, please let me know! --Gershom ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
[Haskell] Spam Control
On Jun 29, 2021, 4:57 AM -0400, Ivan Perez , wrote: > Can we please permanently ban this person and everyone from the > confscience.com domain? > > Thanks, > > Ivan Done. —Gershom ___ Haskell mailing list Haskell@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell
Re: [Haskell-community] Haskell language API copyright status?
See the (very open) license of the Haskell Report https://www.haskell.org/onlinereport/haskell2010/ On Sun, May 24, 2020 at 11:16 AM Nicholas Papadonis < nick.papadonis...@gmail.com> wrote: > Hi Folks, > > You may be aware of Oracle vs. Google in regards to the Java API being > copyrighted. The case is still in progress. > > When the Haskell language was created, including any books on it, the > authors became the copyright holder for the language API that one uses to > code with. Is anyone aware of any license which grants people free use of > this API. I saw various licenses for compilers, but was concerned that was > only for the code implementing the compiler/interpreter. If so, what is it? > > There could be an interpretation that a derivative work of the compiler / > interpreter implementation is indeed the language itself. Therefore if the > compiler / interpreter and it’s derivative is freely licensed, then the > language API is as well. > > I ask because it’s my understanding C/C++ language API was licensed > through ISO, which grants a free license to anyone implementing or using > the language API. > > Appreciate your guidance. > > Thank you, > Nick > ___ > Haskell-community mailing list > Haskell-community@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community > ___ Haskell-community mailing list Haskell-community@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community
[Haskell] Help wanted: Postfix admin guru for Haskell.org
We've been getting increasing amounts of bounces and dropped mail for haskell.org emails (things sent hackage trustees, things sent from our wiki and hackage servers, etc). We _mainly_ have kept things working, but it looks like policies have been amped up in terms of requiring various measures. Additionally, there's something about reverse dns and valid hostnames that seems to not be configured correctly, according to mxtoolbox. Along with all that, we'd really like to migrate the mail infrastructure to our new packet servers, away from rackspace. As such, we could use some concentrated help from someone familiar with maintaining and administering postfix servers, if someone is up to volunteer for the task. Thanks! --Gershom ___ Haskell mailing list Haskell@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell
[Haskell] Final Call for Participation: Compose Conference [NYC, Jun 22- 23 2019]
=== Final Call for Participation Compose Conference 2019 Mon June 24 - Tue June 25 2019 (Unconference on Sat Jun 22 - Sun Jun 23) New York, NY Deadline for registration: June 14 at 11pm EST. http://www.composeconference.org/2019 === The practice and craft of functional programming :: Conference Compose is a conference for typed functional programmers, focused specifically on Haskell, OCaml, F#, SML, and related technologies. Typed functional programming has been taken up widely, by industry and hobbyists alike. For many of us it has renewed our belief that code should be beautiful, and that programming can be as enjoyable as it is practical. Compose is about bringing together functional programmers of all levels of skill and experience — from technical leads to novices, and from long-time hackers to students just getting started. It will feature a two days of great and wide-ranging talks * Invited Keynotes Donya Quick - Making Algorithmic Music David Spivak - Compositional Graphical Logic * Accepted Talks and Tutorials Kenny Foner - Functors of the World, Unite! Phillip Carter - The anatomy of the F# tools for Visual Studio Sebastien Mondet - Genspio: Generating Shell Phrases In OCaml Justin Le - Applicative Regular Expressions using the Free Alternative Gaetano Checinski - Buckaroo SAT - Solving a partially revealed SAT problem for Package Management Richard Feldman - From Rails to Elm and Haskell Samuel Gélineau - Stuck macros: deterministically interleaving macro-expansion and typechecking Vaibhav Sagar - Yes, IHaskell Can Do That! Fintan Halpenny - Bowl Full of Lentils Aditya Siram - A Tase Of ATS Ward Wheeler, Alex Washburn, Callan McGill - Phylogenetic Software in Haskell Igor Trindade Oliveira - Type Driven Secure Enclave Development using Idris David Christiansen - Bidirectional Type Checking Chris Smith - Teaching the intersection of mathematics and functional programming Brandon Kase - Fast Accumulation on Streams James Koppel - The Best Refactoring You’ve Never Heard Of Allister Beharry - Using Dependent Types in an F# DSL for Linear Algebra Diego Balseiro - Bridge Haskell and ReasonML in Production * Full abstracts: http://www.composeconference.org/2019/program * Conference Registration: https://www.eventbrite.com/e/new-york-compose-2019-tickets-56751182314 * Unconference Registration: https://www.eventbrite.com/e/new-york-compose-unconference-2019-tickets-60389859696 * Follow @composeconf on twitter for news: https://twitter.com/composeconf * On freenode irc, chat with fellow attendees at #composeconference * Corporate sponsorships are welcome. Current sponsors list forthcoming. * Policies (diversity and anti-harassment): http://www.composeconference.org/conduct * Email us with any questions at i...@composeconference.org * Please forward this announcement to interested parties and lists. ___ Haskell mailing list Haskell@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell
[Haskell] Announce: Haskell Platform 8.6.5
On behalf of the Haskell Platform team, I'm happy to announce the release of Haskell Platform 8.6.5 Now available at https://www.haskell.org/platform/ This includes GHC 8.6.5, cabal-install 2.4.1.0, and stack 1.9.3. It is an incremental release over 8.6.3 intended mainly to make available bugfixes for windows in subsequent revisions in the 8.6 series and otherwise leave everything the same. These windows fixes are important, and it is recommended all windows users upgrade to 8.6.5 whether through the platform installer or some other mechanism. For detail on these changes and fixes see https://www.haskell.org/ghc/blog/20190305-ghc-8.6.4-released.html https://www.haskell.org/ghc/blog/20190423-ghc-8.6.5-released.html As with the 8.6.3 release, we are only providing core builds. Further, in 8.6.3 we moved from generic linux installers to recommending users install ghc through ghcup. As discussed in the last announcement, we have now moved to recommending os x users also use ghcup rather than a dedicated binary installer. For more details, please see the 8.6.3 announcement at https://mail.haskell.org/pipermail/haskell-cafe/2018-December/130371.html Happy Haskell Hacking all, Gershom ___ Haskell mailing list Haskell@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell
[Haskell] Call for Participation: Compose Conference [NYC, Jun 22- 23 2019]
=== Call for Participation Compose Conference 2019 Mon June 24 - Tue June 25 2019 (Unconference on Sat Jun 22 - Sun Jun 23) New York, NY http://www.composeconference.org/2019 === The practice and craft of functional programming :: Conference Compose is a conference for typed functional programmers, focused specifically on Haskell, OCaml, F#, SML, and related technologies. Typed functional programming has been taken up widely, by industry and hobbyists alike. For many of us it has renewed our belief that code should be beautiful, and that programming can be as enjoyable as it is practical. Compose is about bringing together functional programmers of all levels of skill and experience — from technical leads to novices, and from long-time hackers to students just getting started. It will feature a two days of great and wide-ranging talks * Invited Keynotes Donya Quick - Making Algorithmic Music David Spivak - Compositional Graphical Logic * Accepted Talks and Tutorials Kenny Foner - Functors of the World, Unite! Phillip Carter - The anatomy of the F# tools for Visual Studio Sebastien Mondet - Genspio: Generating Shell Phrases In OCaml Justin Le - Applicative Regular Expressions using the Free Alternative Gaetano Checinski - Buckaroo SAT - Solving a partially revealed SAT problem for Package Management Richard Feldman - From Rails to Elm and Haskell Samuel Gélineau - Stuck macros: deterministically interleaving macro-expansion and typechecking Vaibhav Sagar - Yes, IHaskell Can Do That! Fintan Halpenny - Bowl Full of Lentils Aditya Siram - A Tase Of ATS Ward Wheeler, Alex Washburn, Callan McGill - Phylogenetic Software in Haskell Igor Trindade Oliveira - Type Driven Secure Enclave Development using Idris David Christiansen - Bidirectional Type Checking Chris Smith - Teaching the intersection of mathematics and functional programming Brandon Kase - Fast Accumulation on Streams James Koppel - The Best Refactoring You’ve Never Heard Of Allister Beharry - Using Dependent Types in an F# DSL for Linear Algebra Diego Balseiro - Bridge Haskell and ReasonML in Production * Full abstracts: http://www.composeconference.org/2019/program * Conference Registration: https://www.eventbrite.com/e/new-york-compose-2019-tickets-56751182314 * Unconference Registration: https://www.eventbrite.com/e/new-york-compose-unconference-2019-tickets-60389859696 * Follow @composeconf on twitter for news: https://twitter.com/composeconf * On freenode irc, chat with fellow attendees at #composeconference * Corporate sponsorships are welcome. Current sponsors list forthcoming. * Policies (diversity and anti-harassment): http://www.composeconference.org/conduct * Email us with any questions at i...@composeconference.org * Please forward this announcement to interested parties and lists. ___ Haskell mailing list Haskell@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell
Re: cert on prime expired?
I don’t really have a stake in what happens to it. In my opinion at the very least the domain should point somewhere where there’s a redirect in place to the old content, or some pointer to it, so links don’t die :-) Cheers, Gershom On April 18, 2019 at 11:07:22 PM, Ben Gamari (b...@well-typed.com) wrote: Gershom B writes: > geekosaur> looks like the cert on prime.haskell.org expired 6 days ago > > Ben, I think this is your dept? > I wrote to the Prime committee about their plans for this server but never heard back. In light of this and the lack of traffic on it I was operating on the assumption was that there was no need to keep this server around beyond a static backup. If this isn't the case then we need to work out who is going to be responsible for it since GHC won't be administering a Trac instance once git.haskell.org is decommissioned. I'd be happy to help move the instance to GitLab if that is helpful. Cheers, - Ben ___ Haskell-prime mailing list Haskell-prime@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
[Haskell] Announce: Haskell Platform 8.6.3
On behalf of the Haskell Platform team, I'm happy to announce the release of Haskell Platform 8.6.3 Now available at https://www.haskell.org/platform/ This includes GHC 8.6.3, cabal-install 2.4.1.0, and stack 1.9.3. This is the first platform released in the 8.6 series, as we have waited until a number of bugfix ghc releases stabilized things across all core platforms (linux, os x, windows). A full list of contents is available at https://www.haskell.org/platform/contents.html The list of GHC changes is available at: https://ghc.haskell.org/trac/ghc/blog/ghc-8.6.1-released https://ghc.haskell.org/trac/ghc/blog/ghc-8.6.2-released https://ghc.haskell.org/trac/ghc/blog/ghc-8.6.3-released A list of cabal changes is available at: https://hackage.haskell.org/package/cabal-install-2.4.1.0/changelog A list of stack changes is available at: https://docs.haskellstack.org/en/stable/ChangeLog/#v193 There are a number of important changes in this release, with more changes planned in the future. First: Win32 builds are working again and provided. Thanks to all the folks (especially Tamar) who helped sort out the build issues on that platform. Second, only core builds are provided, not "full" builds. This release is the first one where cabal-install warns on legacy commands and asks users to either use the v1-prefix for them or the v2/new prefix to move to the new-build system. As such, providing additional global packages outside of the core set now makes even less sense than in the past, where we had been already discouraging it for some time. Finally, there are no linux generic builds provided, and instead we recommend use of the ghcup tool (https://github.com/haskell/ghcup/) in combination with the stack install script. We feel this gives a smoother and better experience than the existing install process, being less invasive (not requiring root) and more flexible (by running ghc's own configure script it can better detect differences in configuration between distros). What does this all mean for the future of the platform? What I would like to move towards is the following. First: replacing the mac installer by ghcup as well in the near future. While a native installer has its advantages, the same reasons that ghcup is recommended on linux hold for mac as well, although with somewhat less force. Because of how Windows works, the difficulties of moving from a native installer are much more real, and we would anticipate keeping a native installer for the time being. Second: with the platform installers (or recommended installers) now really a delivery mechanism for core binaries and nothing else, to move to split the platform into two components. A) a set of recommended install instructions for major platforms (and a native windows installer), and B) a set of recommended and known-compatible packages which cover most "extended standard-lib" bases and which we again grow much more freely, as in the past. This will require some redesign and reconceptualization of the website, and would be a great opportunity for people that want to chip-in to move things forward to get involved. Please reach out if you'd like to lend a hand! Happy Haskell Hacking all, Gershom ___ Haskell mailing list Haskell@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell
Re: [cloud-haskell-developers] Does anyone have much experience generating Haskell from Coq?
The other approach, which has been quite successful, by the penn team, is using hs-to-coq to extract coq from haskell and _then_ verify: https://github.com/antalsz/hs-to-coq -g On Sat, Dec 8, 2018 at 7:05 AM Tim Watson wrote: > > So far I've been reading > https://www.cs.purdue.edu/homes/bendy/Fiat/FiatByteString.pdf. I'm interested > in the ideas presented in > https://github.com/DistributedComponents/verdi-runtime, which is OCaml based. > > My goal is to provide building blocks for verifying and testing Cloud Haskell > programs. I've been looking at existing frameworks (such as > quickcheck-state-machine/-distributed and hedgehog) for model based testing, > and ways of injecting an application layer scheduler for detecting race > conditions. The final bit of the puzzle is being able to apply formal methods > to verify concurrent/distributed algorithms, and generate some (if not all) > of the required implementation code. > > Any pointers to research or prior art would be greatly appreciated. > > Cheers, > Tim Watson > > -- > You received this message because you are subscribed to the Google Groups > "cloud-haskell-developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to cloud-haskell-developers+unsubscr...@googlegroups.com. > To post to this group, send email to > cloud-haskell-develop...@googlegroups.com. > Visit this group at https://groups.google.com/group/cloud-haskell-developers. > For more options, visit https://groups.google.com/d/optout. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-community] Creating a new @haskell.org mailing list?
Ok, education@ should now be created, and chris should be list admin. Feel free to reach out to me if there are any issues. Cheers, Gershom On Sat, Nov 17, 2018 at 8:00 PM Chris Smith wrote: > > Any news on this? Would love to help any way I can, but I am not sure what > to do next. > > Thanks, > Chris > > On Wed, Oct 24, 2018 at 3:12 PM Gershom B wrote: >> >> Sounds good. Ccing Sandy, who has volunteered to start helping with >> mail stuff. Sandy -- do you need any further details in setting this >> up, or do you think it should be straightforward? >> >> -g >> On Wed, Oct 24, 2018 at 10:18 AM Chris Smith wrote: >> > >> > Good point, Simon. education@ sounds like a good choice, with the >> > understanding that we mean education for the general population, not >> > classes in type theory or category theory! >> > >> > Is this a possibility? Anything else I can do to move this forward? >> > >> > On Mon, Oct 22, 2018 at 11:32 AM Simon Peyton Jones >> > wrote: >> >> >> >> Good idea. “k12” is rather USA specific. What about >> >> educat...@haskell.org? >> >> >> >> >> >> >> >> Simon >> >> >> >> >> >> >> >> From: Haskell-community On Behalf >> >> Of Chris Smith >> >> Sent: 22 October 2018 15:32 >> >> To: Haskell-community >> >> Subject: [Haskell-community] Creating a new @haskell.org mailing list? >> >> >> >> >> >> >> >> Hey, >> >> >> >> >> >> >> >> Is there a process to request a new mailing list on the haskell.org >> >> domain? >> >> >> >> >> >> >> >> Here's my use case. About 25 Haskell programmers met at ICFP to discuss >> >> uses of Haskell in K-12 education (for non-US readers, that means before >> >> university). I'm also in touch with another half-dozen people who either >> >> have done, or are doing, something pre-university with Haskell, but could >> >> not be at ICFP. The main result of our conversation was that we wanted a >> >> common place to discuss, report on our experiences, look for productive >> >> collaborations and common threads, etc. There are already a few >> >> project-specific places, e.g. the codeworld-discuss mailing list for my >> >> own project, but we were explicitly looking for something general-purpose >> >> and universal. It would be great if this could be, say, >> >> "k...@haskell.org" or something like that. >> >> >> >> >> >> >> >> I'm pretty open in terms of how we'd administer the list. I'm willing to >> >> do the work of handling obvious spam bots and things like that. If >> >> there's a feeling we'd need something more than that, then let's have >> >> that discussion. We explicitly don't want a strict topicality >> >> enforcement, though. For example, several people who attended the dinner >> >> at ICFP were also interested in functional programming for non-majors at >> >> the university level, or were using Elm and other Haskell-like languages >> >> - even a few people from the Racket community. I'd hope to rely on the >> >> name of the mailing list to keep things a bit focused, but not really >> >> police it at all. >> >> >> >> >> >> >> >> Thoughts? >> >> >> >> >> >> >> >> Thanks, >> >> >> >> Chris Smith >> > >> > ___ >> > Haskell-community mailing list >> > Haskell-community@haskell.org >> > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community ___ Haskell-community mailing list Haskell-community@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community
Re: [Haskell-community] 2018 state of Haskell survey results
The language extensions section doesn’t appear to be sorted properly. Outside of that, I think that these results are looking much better and any effort to find any additional outliers is probably not worth it for the moment. Thanks for your work on this, and I appreciate you being responsive and attentive when problems with the data were pointed out. There’s certainly some interesting and helpful information to be gleaned from this data. Cheers, Gershom On November 18, 2018 at 2:55:10 PM, Taylor Fausak (tay...@fausak.me) wrote: Ok, I updated the function that checks for bad responses, re-ran the script, and updated the announcement along with all the assets (charts, tables, and CSV). Hopefully it's the last time, as I can't justify spending much more time on this. https://github.com/tfausak/tfausak.github.io/blob/6f9991758ffeed085c45dd97e4ce6a82a8b1a73f/_posts/2018-11-18-2018-state-of-haskell-survey-results.markdown On Sun, Nov 18, 2018, at 2:32 PM, Michael Snoyman wrote: Just wanted to add in: good catch Gershom on identifying the problem, and thank you Taylor for working to remove them from the report. On 18 Nov 2018, at 21:17, Taylor Fausak wrote: Great catch, Gershom! There are indeed about 300 responses that tick all the boxes except for disliking the new GHC release schedule. The main thing the attacker seemed to be interested in was over-representing Stack and Stackage. Also, bizarrely, Java. That brings the number of bogus responses up to 3,735, which puts the number of legitimate responses at 1,361. For context, last year's survey asked far fewer questions and had 1,335 responses. On Sun, Nov 18, 2018, at 1:26 PM, Imants Cekusins wrote: What if the announcement mentioned a large number of potentially bogus responses, explained the grounds for this conclusion, with a new survey conducted early next year? The next survey would then need to be done differently from this one somehow. To improve the reliability, some authentication may be necessary. Maybe Stack, Cabal questions could be grouped as separate distinct surveys, conducted by their maintainers through own channels? Not sure how much value is in exact numbers of users of Stack or Cabal. Both groups are large enough. The maintainers of both groups are aware about usage stats. Is either library likely to be influenced by this survey? *___* Haskell-community mailing list Haskell-community@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community ___ Haskell-community mailing list Haskell-community@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community ___ Haskell-community mailing list Haskell-community@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community ___ Haskell-community mailing list Haskell-community@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community
Re: [Haskell-community] 2018 state of Haskell survey results
Hi Taylor. I think we're closer to the real results here, but I'm still pretty sure that there are a fair number of phony responses. In particular, looking at your filter function, I don't think that _all_ bogus responses said "I dislike it" with regards to the ghc release schedule. A fair number that hit all the other criteria also seem to have left it blank. I suspect this will be enough to do the trick, but can't be sure... This attempted sabotage of the survey is really frustrating and disappointing. -g On Sun, Nov 18, 2018 at 10:58 AM Taylor Fausak wrote: > > I have filtered out the bogus responses and re-generated all the charts and > tables. You can see the updated results here: > https://github.com/tfausak/tfausak.github.io/blob/ee29da5bd8389c19763ac2b4dbe27ff5204161f5/_posts/2018-11-16-2018-state-of-haskell-survey-results.markdown > > Note that until I post the results on my blog, they are not published. Please > don't share the preliminary results on social media! > > > On Sun, Nov 18, 2018, at 8:11 AM, Taylor Fausak wrote: > > Thanks for finding those anomalies, Gershom! I'm disappointed that someone > submitted bogus responses, apparently to tip the scales of Cabal versus > Stack. I intend to identify those responses and exclude them from the > results. The work you've done so far will help a great deal in finding them. > > You said that there are about 1,200 responses with demographic information. > That makes sense considering the number of submissions I got last year. Also, > there are 1,185 responses that included an answer to at least one of the > free-response questions. So perhaps whoever wrote the script didn't bother to > put an answer for those types of questions. > > Unfortunately I do not have precise submission times or IP address > information about submissions. Beyond what's in the CSV, the only other thing > I have is (some) email addresses. > > Fortunately I wrote a script to output all the charts and tables from the > survey responses. Once I've identified the problematic responses, I should be > able to update the script to ignore them and regenerate all the output. > > > On Sun, Nov 18, 2018, at 3:40 AM, Chris Smith wrote: > > Sadly, it looks like a Cabal/Stack thing. Of the responses with a country > provided, 618 of 1226 claim to use Cabal, and 948 of 1226 claim to use Stack. > Of the responses with no country, only 35 of 3868 claim to use Cabal, while > 3781 of the 3868 claim to use Stack. Assuming independence, you'd expect > that last number to be about 50, meaning there are probably around 3700 fake > responses generated just to answer "Stack". > > To partially answer Simon's question, the flood of no-demographics responses > started on November 2, around the 750-response point, and continued unabated > through the close of the survey. And, indeed, looking at just the first 750 > responses gives similar distributions to what we get by ignoring the > no-demographic responses. For example, of the first 750 responses, 359 claim > to use Cabal, and 568 claim to use Stack. > > On Sun, Nov 18, 2018 at 2:31 AM Simon Marlow wrote: > > Good spot Gershom. Maybe it would be revealing to look at the times that > responses were received for the no-demographics group? > > On Sun, 18 Nov 2018, 07:17 Gershom B > I also noticed a number of other bizarre statistical anomolies when looking > at the full results. I know this is a bit much to ask — but if you could > rerun the statistics filtering out people that did not give demographic > information (i.e. country of origin or education, etc) I think the results > will change drastically. By all statistical logic, this should _not_ be the > case, and points to a serious problem. > > In particular, this drops the results by a huge amount — only 1,200 or so > remain. However, the remaining results tend to make a lot more sense. For > example — of the “no demographics” group, there are 713 users who claim to > develop with notepad++ but all of these say they develop on mac and linux, > and none on windows — which is impossible, as notepad++ is a windows program. > Further if you drop the “no demographics” group, then you find that almost > everyone uses at least ghc 8.0.2, while in the “no demographics” group, a > stunning number of people claim to be on 7.8.3. Even more bizarrely, people > claim to be using the 7.8 series while only having used Haskell for less than > one year. And people claim to have used haskell for “one week to one month” > and also to be advanced and expert users! > > The differences continue and defy all probability. Of the “no demographics” > group, almost everyone dislikes the new release schedule. Of the > “demographi
Re: [Haskell-community] 2018 state of Haskell survey results
I also noticed a number of other bizarre statistical anomolies when looking at the full results. I know this is a bit much to ask — but if you could rerun the statistics filtering out people that did not give demographic information (i.e. country of origin or education, etc) I think the results will change drastically. By all statistical logic, this should _not_ be the case, and points to a serious problem. In particular, this drops the results by a huge amount — only 1,200 or so remain. However, the remaining results tend to make a lot more sense. For example — of the “no demographics” group, there are 713 users who claim to develop with notepad++ but all of these say they develop on mac and linux, and none on windows — which is impossible, as notepad++ is a windows program. Further if you drop the “no demographics” group, then you find that almost everyone uses at least ghc 8.0.2, while in the “no demographics” group, a stunning number of people claim to be on 7.8.3. Even more bizarrely, people claim to be using the 7.8 series while only having used Haskell for less than one year. And people claim to have used haskell for “one week to one month” and also to be advanced and expert users! The differences continue and defy all probability. Of the “no demographics” group, almost everyone dislikes the new release schedule. Of the “demographics” group there are answers that like it, were not aware of it, or are indifferent, but almost nobody dislikes it. There is naturally a difference in proportions of cabal/stack and hackage/stackage responses as well. There are a lot of other things I could point to as well. But, bluntly put, I think that some disaffected party or parties wrote a crude script and submitted over 3,000 fake responses. Luckily for us, they were not very smart, and made some obvious errors, so in this case we can weed out the bad responses (although, sadly, losing at least a few real ones as well). However, assuming this party isn’t entirely stupid, it doesn’t bode well for future surveys as they may get at least slightly less dumb in the future if they decide to keep it up :-/ —Gershom On November 18, 2018 at 1:10:31 AM, Gershom B (gersh...@gmail.com) wrote: This is interesting, but I’m thoroughly confused. Over 2500 people said they took last year’s survey, but it only had roughly 1,300 respondants? On Sat, Nov 17, 2018 at 9:56 PM Taylor Fausak wrote: > Hello! It took a little longer than I expected, but I am nearly ready to > announce the 2018 state of Haskell survey results. Some community members > have expressed interest in seeing the announcement post before it's > published. If you are one of those people, you can see the results here: > https://github.com/tfausak/tfausak.github.io/blob/7e4937e284a3068add9e9af6b585c8d0215ff360/_posts/2018-11-16-2018-state-of-haskell-survey-results.markdown > > If you would like to suggest changes to the announcement post, please > respond to this email, send me an email directly, or reply to this pull > request on GitHub: https://github.com/tfausak/tfausak.github.io/pull/148 > > I plan on publishing the results tomorrow. Once the results are published, > the post is by no means set in stone. I will happily accept suggestions > from anyone at any time. > > Thank you! > ___ > Haskell-community mailing list > Haskell-community@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community > ___ Haskell-community mailing list Haskell-community@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community
Re: [Haskell-community] Creating a new @haskell.org mailing list?
Sounds good. Ccing Sandy, who has volunteered to start helping with mail stuff. Sandy -- do you need any further details in setting this up, or do you think it should be straightforward? -g On Wed, Oct 24, 2018 at 10:18 AM Chris Smith wrote: > > Good point, Simon. education@ sounds like a good choice, with the > understanding that we mean education for the general population, not classes > in type theory or category theory! > > Is this a possibility? Anything else I can do to move this forward? > > On Mon, Oct 22, 2018 at 11:32 AM Simon Peyton Jones > wrote: >> >> Good idea. “k12” is rather USA specific. What about educat...@haskell.org? >> >> >> >> Simon >> >> >> >> From: Haskell-community On Behalf Of >> Chris Smith >> Sent: 22 October 2018 15:32 >> To: Haskell-community >> Subject: [Haskell-community] Creating a new @haskell.org mailing list? >> >> >> >> Hey, >> >> >> >> Is there a process to request a new mailing list on the haskell.org domain? >> >> >> >> Here's my use case. About 25 Haskell programmers met at ICFP to discuss >> uses of Haskell in K-12 education (for non-US readers, that means before >> university). I'm also in touch with another half-dozen people who either >> have done, or are doing, something pre-university with Haskell, but could >> not be at ICFP. The main result of our conversation was that we wanted a >> common place to discuss, report on our experiences, look for productive >> collaborations and common threads, etc. There are already a few >> project-specific places, e.g. the codeworld-discuss mailing list for my own >> project, but we were explicitly looking for something general-purpose and >> universal. It would be great if this could be, say, "k...@haskell.org" or >> something like that. >> >> >> >> I'm pretty open in terms of how we'd administer the list. I'm willing to do >> the work of handling obvious spam bots and things like that. If there's a >> feeling we'd need something more than that, then let's have that discussion. >> We explicitly don't want a strict topicality enforcement, though. For >> example, several people who attended the dinner at ICFP were also interested >> in functional programming for non-majors at the university level, or were >> using Elm and other Haskell-like languages - even a few people from the >> Racket community. I'd hope to rely on the name of the mailing list to keep >> things a bit focused, but not really police it at all. >> >> >> >> Thoughts? >> >> >> >> Thanks, >> >> Chris Smith > > ___ > Haskell-community mailing list > Haskell-community@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community ___ Haskell-community mailing list Haskell-community@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community
Re: [Haskell-community] 2018 state of Haskell survey
ng in only 6 months.) > > > > Incidentally, I for one think that it's a Good Thing that you included > > FP Complete's survey in the HWN, Taylor. First, I think it's a > > substantial and interesting piece of work -- and /any/ survey is > > vulnerable to response bias. Second, I don’t think anyone should expect > > you as HWN editor to play a role as community censor. Third, > > deliberately excluding it would in itself be a divisive act in a > > community that needs less division and more love. > > > > You do a fantastic job with HWN. Please keep doing it! > > > > Thanks > > > > Simon > > > > | -Original Message- > > | From: Haskell-community On > > | Behalf Of Gershom B > > | Sent: 15 October 2018 01:56 > > | To: tay...@fausak.me; Mathieu Boespflug ; Ben Gamari > > | > > | Cc: haskell-community@haskell.org > > | Subject: Re: [Haskell-community] 2018 state of Haskell survey > > | > > | (cc mathieu boespflug, ben gamari) > > | > > | One more thought: > > | > > | mathieu, ben -- do you think you would be interested in any questions > > | on the frequency of ghc releases -- if people appreciate more > > | frequent, smaller releases, or not, etc? > > | > > | I wonder if there are any other questions as well about core libraries > > | vs. performance vs. "big features" (like type system things) vs. small > > | ergonomic features etc. that the core ghc team might be interested in > > | sounding out people on, bearing in mind the necessary limitations of > > | survey derived data. > > | > > | --g > > | On Sun, Oct 14, 2018 at 8:36 PM Gershom B wrote: > > | > > > | > Hi Taylor. > > | > > > | > We're discussing this in the committee. I agree that to the extent > > | > they can accurately reflect something, language surveys are useful, > > | > and appreciate that you want to run a useful survey, and certainly > > | > want to encourage and help you in making it as broad and useful as > > | > possible. That said, I don't know if slapping a "haskell.org" label on > > | > the survey will help manage the biggest drivers of selection bias -- > > | > which is not only about who chooses to respond, but about who is > > | > reached through what mechanisms. (I don't know the relative importance > > | > of response-bias vs. outreach-bias in general, and would be curious if > > | > somebody has some good research on that to point to). I honestly don't > > | > know if we have enough channels _in general_ to do a good survey, no > > | > matter who runs it or how at all! Regardless of the decision we come > > | > to, here are a few of my personal thoughts on the questions you have > > | > thus far, and what could be added: > > | > > > | > 1) A question "how did you hear about this survey" -- this could at > > | > least help to disentangle outreach-bias, or notice it, depending on if > > | > it induces any correlations. > > | > > > | > 2) A question on how long after a new GHC release users upgrade -- > > | > both personally, and at work. > > | > > > | > 3) Distinguishing between personal and work build-systems in the > > | > relevant question. > > | > > > | > 4) I think the sorts of questions that make sense to ask in this early > > | > part can resemble those in the first part of the Go survey: > > | > > > | https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fblog.go > > | lang.org%2Fsurvey2017- > > | resultsdata=02%7C01%7Csimonpj%40microsoft.com%7C9fbbfac1fd9e420bbf2 > > | 008d63238f7c4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6367516175958 > > | 02229sdata=2wB5Ph5%2Be6wZm0CWP7Yzx%2Fxe4dOlKHqNPKZReiJmE50%3Dr > > | eserved=0 (I especially like the > > | > questions about the area of development and server vs cli apps vs > > | > libraries). I also like their questions about what environments teams > > | > deploy programs to. It would also be worth asking if the apps > > | > developed are customer-facing or internal. > > | > > > | > 5) I think an interesting question would be what preferred js > > | > solution, if any, teams adopt -- i.e. ghcjs, typescript, purescript, > > | > raw js, etc. > > | > > > | > 6) for the "why did you stop" question, there are a good range of > > | > potential multi-choice answers that can be drawn from with the rust > > | > user survey: > > | https://na01.safelinks.protection
Re: [Haskell-community] 2018 state of Haskell survey
(cc mathieu boespflug, ben gamari) One more thought: mathieu, ben -- do you think you would be interested in any questions on the frequency of ghc releases -- if people appreciate more frequent, smaller releases, or not, etc? I wonder if there are any other questions as well about core libraries vs. performance vs. "big features" (like type system things) vs. small ergonomic features etc. that the core ghc team might be interested in sounding out people on, bearing in mind the necessary limitations of survey derived data. --g On Sun, Oct 14, 2018 at 8:36 PM Gershom B wrote: > > Hi Taylor. > > We're discussing this in the committee. I agree that to the extent > they can accurately reflect something, language surveys are useful, > and appreciate that you want to run a useful survey, and certainly > want to encourage and help you in making it as broad and useful as > possible. That said, I don't know if slapping a "haskell.org" label on > the survey will help manage the biggest drivers of selection bias -- > which is not only about who chooses to respond, but about who is > reached through what mechanisms. (I don't know the relative importance > of response-bias vs. outreach-bias in general, and would be curious if > somebody has some good research on that to point to). I honestly don't > know if we have enough channels _in general_ to do a good survey, no > matter who runs it or how at all! Regardless of the decision we come > to, here are a few of my personal thoughts on the questions you have > thus far, and what could be added: > > 1) A question "how did you hear about this survey" -- this could at > least help to disentangle outreach-bias, or notice it, depending on if > it induces any correlations. > > 2) A question on how long after a new GHC release users upgrade -- > both personally, and at work. > > 3) Distinguishing between personal and work build-systems in the > relevant question. > > 4) I think the sorts of questions that make sense to ask in this early > part can resemble those in the first part of the Go survey: > https://blog.golang.org/survey2017-results (I especially like the > questions about the area of development and server vs cli apps vs > libraries). I also like their questions about what environments teams > deploy programs to. It would also be worth asking if the apps > developed are customer-facing or internal. > > 5) I think an interesting question would be what preferred js > solution, if any, teams adopt -- i.e. ghcjs, typescript, purescript, > raw js, etc. > > 6) for the "why did you stop" question, there are a good range of > potential multi-choice answers that can be drawn from with the rust > user survey: > https://blog.rust-lang.org/2017/09/05/Rust-2017-Survey-Results.html > > Cheers, > Gershom > > On Sun, Oct 14, 2018 at 3:32 PM Taylor Fausak wrote: > > > > I'm not entirely sure what official support would look like. A few things > > come to mind: > > > > 1. Simply putting "official" somewhere in the title, such as: Official 2018 > > state of Haskell survey. > > > > 2. Putting something about Haskell.org in the description of the survey, > > such as: Sponsored by Haskell.org. > > > > 3. Announcing the survey through channels that I may not be aware of. Or > > helping me announce the survey through various channels (mailing lists, > > Reddit, and so on) by mentioning Haskell.org. > > > > I'm sure there are more ways that I'm not thinking of. > > > > Perhaps it would be better to state my goal and see what, if anything, can > > be to achieve that goal? My goal is for this survey to be *the* > > authoritative Haskell survey and for the community to broadly accept it > > results. In particular I would like to avoid reactions like these to the > > recent FP Complete survey: > > > > > I browse r/haskell all the time and follow FPco on Twitter, and I wasn't > > > aware of this survey. [1] > > > > > It should not be surprising to think that fp complete has much better > > > outreach to Stackage users than to non Stackage users. [2] > > > > > Any survey hosted by FPComplete is biased towards users of stack, for > > > reasons that should be self evident. [3] > > > > Similar sentiments have been expressed about last year's Haskell Weekly > > survey: > > > > > Haskell Weekly's reputation is tainted as it appears to be seen as > > > partisan (and I tend to agree). [4] > > > > > one of those surveys is from FP Complete and one of them is from someone > > > who I would consider very partisan in these kind of d
Re: [Haskell-community] 2018 state of Haskell survey
Hi Taylor. We're discussing this in the committee. I agree that to the extent they can accurately reflect something, language surveys are useful, and appreciate that you want to run a useful survey, and certainly want to encourage and help you in making it as broad and useful as possible. That said, I don't know if slapping a "haskell.org" label on the survey will help manage the biggest drivers of selection bias -- which is not only about who chooses to respond, but about who is reached through what mechanisms. (I don't know the relative importance of response-bias vs. outreach-bias in general, and would be curious if somebody has some good research on that to point to). I honestly don't know if we have enough channels _in general_ to do a good survey, no matter who runs it or how at all! Regardless of the decision we come to, here are a few of my personal thoughts on the questions you have thus far, and what could be added: 1) A question "how did you hear about this survey" -- this could at least help to disentangle outreach-bias, or notice it, depending on if it induces any correlations. 2) A question on how long after a new GHC release users upgrade -- both personally, and at work. 3) Distinguishing between personal and work build-systems in the relevant question. 4) I think the sorts of questions that make sense to ask in this early part can resemble those in the first part of the Go survey: https://blog.golang.org/survey2017-results (I especially like the questions about the area of development and server vs cli apps vs libraries). I also like their questions about what environments teams deploy programs to. It would also be worth asking if the apps developed are customer-facing or internal. 5) I think an interesting question would be what preferred js solution, if any, teams adopt -- i.e. ghcjs, typescript, purescript, raw js, etc. 6) for the "why did you stop" question, there are a good range of potential multi-choice answers that can be drawn from with the rust user survey: https://blog.rust-lang.org/2017/09/05/Rust-2017-Survey-Results.html Cheers, Gershom On Sun, Oct 14, 2018 at 3:32 PM Taylor Fausak wrote: > > I'm not entirely sure what official support would look like. A few things > come to mind: > > 1. Simply putting "official" somewhere in the title, such as: Official 2018 > state of Haskell survey. > > 2. Putting something about Haskell.org in the description of the survey, such > as: Sponsored by Haskell.org. > > 3. Announcing the survey through channels that I may not be aware of. Or > helping me announce the survey through various channels (mailing lists, > Reddit, and so on) by mentioning Haskell.org. > > I'm sure there are more ways that I'm not thinking of. > > Perhaps it would be better to state my goal and see what, if anything, can be > to achieve that goal? My goal is for this survey to be *the* authoritative > Haskell survey and for the community to broadly accept it results. In > particular I would like to avoid reactions like these to the recent FP > Complete survey: > > > I browse r/haskell all the time and follow FPco on Twitter, and I wasn't > > aware of this survey. [1] > > > It should not be surprising to think that fp complete has much better > > outreach to Stackage users than to non Stackage users. [2] > > > Any survey hosted by FPComplete is biased towards users of stack, for > > reasons that should be self evident. [3] > > Similar sentiments have been expressed about last year's Haskell Weekly > survey: > > > Haskell Weekly's reputation is tainted as it appears to be seen as partisan > > (and I tend to agree). [4] > > > one of those surveys is from FP Complete and one of them is from someone > > who I would consider very partisan in these kind of discussions. [5] > > > For the love of god stop posting those surveys. They're not convincing and > > obviously flawed. [6] > > I don't expect to be able to make everyone happy, but I think that presenting > this year's survey as sponsored by both Haskell Weekly and Haskell.org would > go a long way toward making it acceptable to a broad range of the Haskell > community. > > I hope that helps! > > [1]: > https://np.reddit.com/r/haskell/comments/9mm05d/2018_haskell_survey_results/e7gplya/ > [2]: > https://np.reddit.com/r/haskell/comments/8tc8pr/fp_complete_launches_new_blockchain_auditing/e188ftv/?context=3 > [3]: > https://np.reddit.com/r/haskell/comments/9mm05d/2018_haskell_survey_results/e7gpfwe/ > [4]: > https://np.reddit.com/r/haskell/comments/9mm05d/2018_haskell_survey_results/e7ka8xn/ > [5]: > https://np.reddit.com/r/haskell/comments/8tc8pr/fp_complete_launches_new_blockchain_auditing/e187pzq/?context=1 > [6]: > https://np.reddit.com/r/haskell/comments/8uw9hw/psa_cabal_breaks_with_yaml0831_on_ghc_710_and/e1lfzgr/?context=1 > > > On Sun, Oct 14, 2018, at 2:21 PM, Neil Mitchell wrote: > > Hi Taylor, > > What does official support look like? I don't think there's anything above > and
Re: Quo vadis?
Mario: as a non-committee member but interested observer, if you yourself
wanted to proceed to put the report in the repo, what obstacles would stand in
your way, and could we clear them out so you could take charge of that task?
Cheers,
Gershom
On October 7, 2018 at 9:52:14 PM, Mario Blažević (blama...@ciktel.net) wrote:
On 2018-10-05 01:05 PM, Simon Peyton Jones wrote:
> I think the difficulty has always been in finding enough people who are
>
> * Well-informed and well-qualified
> * Willing to spend the time to standardise language features
>
> GHC does not help the situation: it's a de-facto standard, which reduces the
> incentives to spend time in standardisation.
>
> I don’t think we should blame anyone for not wanting to invest this time --
> no shame here. It is a very significant commitment, as I know from editing
> the Haskell 98 report and the incentives are weak. Because of that, I am not
> very optimistic about finding such a group -- we have been abortively trying
> for several years.
That sounds like we're stuck with the committee we have. In that case,
Simon, could you at least pull some strings to have the actual Haskell
Report placed in the same repository? This is a basic precondition if we
expect individual efforts to accomplish anything. The minimal steps to
actually updating the Haskell Report are:
1. write an RFC (we have some already),
2. have it provisionally accepted (not entirely clear how - would
"no negative votes in 4 weeks" count?),
3. add the modification to the Haskell Report to the RFC,
4. receive the final approval,
5. merge the RFC into the report.
Steps #3 and #5 depend on having the report in the same repository with
the RFCs. This has been agreed over a year ago:
https://mail.haskell.org/pipermail/haskell-prime/2017-September/004319.html
https://mail.haskell.org/pipermail/haskell-prime/2017-October/thread.html
https://mail.haskell.org/pipermail/haskell-prime/2017-November/thread.html
https://mail.haskell.org/pipermail/haskell-prime/2018-March/004356.html
> If we want to change that, the first thing is to build a case that greater
> standardisation is not just an "abstract good" that we all subscribe to, but
> something whose lack is holding us back.
Neither an abstract good nor a good abstraction are something Haskell
has ever shied away from. I don't know if you're actually asking for a
list of "concrete goods"? To start with, every GHC extension that's
added to a standard means:
- one less item to type in the ubiquitous {-# LANGUAGE ScaryExtension
#-} pragma,
- one less item to understand for beginners,
- one less item whose necessity must be justified to the team, and
- one less item of whose future stability the management needs to be
convinced.
I could go on.
___
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: [Haskell] Announce: Haskell Platform 8.4.3
As a brief followup, new 8.4.3 installers for windows have been released (both core and full), which resolve a few issues brought about by the switch to automatic modification of "extra-prog-path" and related, and the corresponding hashes have been updated. Best, Gershom On Tue, Jun 12, 2018 at 7:27 AM Gershom B wrote: > > On behalf of the Haskell Platform team, I'm happy to announce the release of > > Haskell Platform 8.4.3 > > Now available at > > https://www.haskell.org/platform/ > > This includes GHC 8.4.3, cabal-install 2.2.0.0, and stack 1.7.1. > > A full list of contents is available at > https://www.haskell.org/platform/contents.html > > Outside of the update of the GHC to 8.4.3, the only substantive change > in this release is to the new version of the primitive library, which > includes a range of fixes and improvements. > > The list of GHC changes is available at: > https://ghc.haskell.org/trac/ghc/blog/ghc-8.4.3-released > > And the list of changes to Primitive is available at: > http://hackage.haskell.org/package/primitive-0.6.4.0/changelog > > There are (still) currently no 32 bit Windows builds available. We're > looking into the issues preventing us from building an installer for > that platform. The components all appear to work individually in such > a case, and can be installed separately by users who so desire. > > Happy Haskell Hacking all, > Gershom ___ Haskell mailing list Haskell@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell
[Haskell] Announce: Haskell Platform 8.4.3
On behalf of the Haskell Platform team, I'm happy to announce the release of Haskell Platform 8.4.3 Now available at https://www.haskell.org/platform/ This includes GHC 8.4.3, cabal-install 2.2.0.0, and stack 1.7.1. A full list of contents is available at https://www.haskell.org/platform/contents.html Outside of the update of the GHC to 8.4.3, the only substantive change in this release is to the new version of the primitive library, which includes a range of fixes and improvements. The list of GHC changes is available at: https://ghc.haskell.org/trac/ghc/blog/ghc-8.4.3-released And the list of changes to Primitive is available at: http://hackage.haskell.org/package/primitive-0.6.4.0/changelog There are (still) currently no 32 bit Windows builds available. We're looking into the issues preventing us from building an installer for that platform. The components all appear to work individually in such a case, and can be installed separately by users who so desire. Happy Haskell Hacking all, Gershom ___ Haskell mailing list Haskell@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell
PSA for Cabal 2.2 new-* users regarding .ghc.environment files
There is an important change in the cabal new- commands for 2.2 that the release docs should have highlighted more significantly. Cabal new-* commands now produce a .ghc.environment file by default. These files [1] are picked up by ghc and ghci automatically (since 8.0.1), and allow them to operate directly with the same package environment used by the new-* commands. This lets you, for example, run `ghci` in a project where you are using `new-build` and get the proper dependencies in scope. Herbert has written an experimental tool to make it easier to create and manipulate these environments [2]. However: there is a drawback (on which some discussion at [3] and [4]. In particular, there is not good information provided by ghc about when these files are picked up and used. So if you are admixing new-* commands and other commands for the time being, jumping between the two, or admixing ghc and ghcjs, etc., then you may run into unexpected behavior! [5] The simplest solution for now is to delete the local .ghc.environment file in those cases (i.e. where you're mixing commands and get unexpected behavior). A particular gotcha is that these files are picked up not just in the current directory but also in any parent directory. Cheers, Gershom [1] documented at https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/packages.html#package-environments [2] https://github.com/hvr/cabal-env [3] https://github.com/haskell/cabal/issues/4542 [4] https://ghc.haskell.org/trac/ghc/ticket/13753 [5] Error messages may be like ".cabal/store/ghc-8.0.2/package.db/package.cache: openBinaryFile: does not exist (No such file or directory)" or complaints about missing inplace dependencies. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: [Haskell] Announce: Haskell Platform 8.4.2
One additional feature I forgot to note: the windows platform installers should no longer require manually altering the cabal config file to add `extra-prog-path`, etc. to point to the msys distribution. The new windows installer takes advantage of the `cabal user-config --augment` command to add those lines automatically. This should give a smoother install experience for new windows users. --gershom On Sat, May 5, 2018 at 2:16 AM, Gershom B <gersh...@gmail.com> wrote: > On behalf of the Haskell Platform team, I'm happy to announce the release of > > Haskell Platform 8.4.2 > > Now available at > > https://www.haskell.org/platform/ > > This includes GHC 8.4.2, cabal-install 2.2.0.0, and stack 1.7.1, all > with substantial improvements since the last platform release. > > A full list of contents is available at > https://www.haskell.org/platform/contents.html > > Thanks to all the contributors to this release, thanks to all the > package and tool maintainers and authors, and a big thanks to the GHC > team for all their hard work. > > There are (still) currently no 32 bit Windows builds available. We're > looking into the issues preventing us from building an installer for > that platform. The components all appear to work individually in such > a case, and can be installed separately by users who so desire. > > A list of new GHC changes is available at: > https://ghc.haskell.org/trac/ghc/blog/ghc-8.4.1-released and > https://ghc.haskell.org/trac/ghc/blog/ghc-8.4.2-released > > A list of cabal changes is available at: > https://hackage.haskell.org/package/cabal-install-2.2.0.0/changelog > > The cabal documentation page is at: > https://www.haskell.org/cabal/users-guide/ > > A list of stack changes is at: > https://docs.haskellstack.org/en/stable/ChangeLog/#v171 > > The stack documentation page is at: > https://docs.haskellstack.org/en/stable/README/ > > Happy Haskell Hacking all, > Gershom ___ Haskell mailing list Haskell@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell
[Haskell] Announce: Haskell Platform 8.4.2
On behalf of the Haskell Platform team, I'm happy to announce the release of Haskell Platform 8.4.2 Now available at https://www.haskell.org/platform/ This includes GHC 8.4.2, cabal-install 2.2.0.0, and stack 1.7.1, all with substantial improvements since the last platform release. A full list of contents is available at https://www.haskell.org/platform/contents.html Thanks to all the contributors to this release, thanks to all the package and tool maintainers and authors, and a big thanks to the GHC team for all their hard work. There are (still) currently no 32 bit Windows builds available. We're looking into the issues preventing us from building an installer for that platform. The components all appear to work individually in such a case, and can be installed separately by users who so desire. A list of new GHC changes is available at: https://ghc.haskell.org/trac/ghc/blog/ghc-8.4.1-released and https://ghc.haskell.org/trac/ghc/blog/ghc-8.4.2-released A list of cabal changes is available at: https://hackage.haskell.org/package/cabal-install-2.2.0.0/changelog The cabal documentation page is at: https://www.haskell.org/cabal/users-guide/ A list of stack changes is at: https://docs.haskellstack.org/en/stable/ChangeLog/#v171 The stack documentation page is at: https://docs.haskellstack.org/en/stable/README/ Happy Haskell Hacking all, Gershom ___ Haskell mailing list Haskell@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell
[Haskell] Unplanned Hackage Downtime
I made a terrible administrative snafu, and we need to take some time to restore Hackage. Luckily we have better mirroring in place now, so cabal-install should be able to fall back automatically to mirrors. If this does not work, you can use http://objects-us-west-1.dream.io/hackage-mirror/ or http://hackage.fpcomplete.com/ manually. Best (and sincere apologies), Gershom ___ Haskell mailing list Haskell@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell
[Haskell-community] New Videos for Haskell.org Homepage
I wanted to call people's attention to this PR: https://github.com/haskell-infra/hl/pull/229 The videos are overdue for updating, and the suggestions look good to me, but a bit more feedback (even if just a flood of thumbs ups :-)) wouldn't hurt before pulling the trigger. -g ___ Haskell-community mailing list Haskell-community@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community
Place to report non-textual (markup) issues on the haskell report?
In reviewing tickets, I noticed the following: https://github.com/haskell-infra/hl/issues/172 This is not an issue about the haskell homepage, but about the markup of the report, with some suggestions on how to make it easier to navigate. The github repo for the report does not seem to have “issues” turned on — I suppose to discourage filing issues against the report itself, for which there is a different process. Nonetheless, I would like to get this information captured in some appropriate place/way. I added a label for `haskell-report` to the issue, which I guess is a start. Further suggestions? —Gershom ___ Haskell-prime mailing list Haskell-prime@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
[Haskell-community] hackage redesign discussions
If people want to participate there are now a space of design and ux-tickets on the hackage tracker. I've tried to tag them all with "discussion". https://github.com/haskell/hackage-server/issues Hopefully I can collect small changes and make style-only update compound update proposal, that will be followed by a small style-only update to the main server. This is important because we want everything to be largely settled for the haddock release, to ensure that the final design of it meshes with what we iterate to on hackage: https://github.com/haskell/haddock/pull/721 -g ___ Haskell-community mailing list Haskell-community@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community
[Haskell-community] new governance page on wiki
I created this page to help further factor out and centralize information about he profusion of bodies we now have, and help direct people where they may want to go to report issues: https://wiki.haskell.org/Haskell_Governance It should be a useful place to direct people to when they want to know "who do I talk to about X issue”. --Gershom ___ Haskell-community mailing list Haskell-community@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community
Re: [Haskell] [Google Summer of Code 2018] Student Applications are now open
On March 16, 2018 at 7:08:20 AM, Tillmann Vogt (tillmann.v...@rwth-aachen.de(mailto:tillmann.v...@rwth-aachen.de)) wrote: > I know I know. I am supposed to just ignore this. You most likely just > copied it from a template. The people with the money want control over > our minds. And we should better not complain or there will be no GSOC > next year. SCNR. This was not mindlessly copied from a template, and it was not imposed by google. This was written by the people involved in the Haskell GSoC work, because we meant it. It was not written to ask people to ignore. It was written to ask people to consider, and to indicate that we understand that in drawing people into the world of free software development, we should take pains to make the tools we build and use as widely accessible as possible. We want to share the joy of functional programming with everyone, and that means, especially that we want to help foster Haskell among those that are, thus far, historically underrepresented in the world of functional programming. I think it is a good thing. Best, Gershom (p.s. This list is intended to be low-traffic and for announcements. Future discussion on this list would be off topic. If people would like discussion to continue, I suggest haskell-cafe). ___ Haskell mailing list Haskell@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell
[Haskell] ANN: Hackage Account Registration Changes
As some people have seen, a spammer has started to create accounts on hackage to upload fake packages, in order to use their package-descriptions for linkspam. We'll be working to clean-up the package-index from this spam, and the accounts have been disabled. Further, we'll need to decide on some long-term changes going forward to make this sort of abuse more difficult. In the meantime, as a short term measure, we have changed new account registration policies on hackage. Users can still register as before, but new users do _not_ have upload rights until they explicitly request them and are granted them by a human being. (This is actually how we had configured hackage to work on initial deployment -- we loosened things up for some years as the extra step seemed unnecessary). Apologies for the inconvenience, but this seemed the most direct way to stop the current influx of spam. Users with existing hackage accounts should encounter no differences in behavior. Best, Gershom ___ Haskell mailing list Haskell@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell
[Haskell] PSA: `cabal update` command needs manual unsticking
Dear Haskellers, A recent update to hackage, which fixed up the 01-index.tar.gz file, revealed a bug in existing versions of cabal-install, when index files are cleaned up. This bug means that the `cabal update` command, which updates the hackage index file, will fail silently and leave the old file in place. It is easy to get things working again, but it requires manual intervention. Here is the most straightforward way to get things working again: On gnu/linux or mac: rm ~/.cabal/packages/hackage.haskell.org/01-index.* On windows: remove the same files, but from %appdata%\cabal\packages\hackage.haskell.org rerun `cabal update` to fetch a new 01-index. Apologies all for the inconvenience and any confusion this may have caused. There is a PR to fix this behavior in the works, but since the problem is on the client side, the fix will only improve the situations for new versions of `cabal`. Happy New Years to all, and cheers to a very functional 2018, Gershom p.s.: since the problem comes in unpacking the 01-index.tar.gz into the 01-index.tar, you can also just untar that file in place manually, or force cabal into doing the same by running `touch ~/.cabal/packages/hackage.haskell.org/01-index.tar` ___ Haskell mailing list Haskell@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell
PSA: `cabal update` command needs manual unsticking
Dear Haskellers, A recent update to hackage, which fixed up the 01-index.tar.gz file, revealed a bug in existing versions of cabal-install, when index files are cleaned up. This bug means that the `cabal update` command, which updates the hackage index file, will fail silently and leave the old file in place. It is easy to get things working again, but it requires manual intervention. Here is the most straightforward way to get things working again: On gnu/linux or mac: rm ~/.cabal/packages/hackage.haskell.org/01-index.* On windows: remove the same files, but from %appdata%\cabal\packages\hackage.haskell.org rerun `cabal update` to fetch a new 01-index. Apologies all for the inconvenience and any confusion this may have caused. There is a PR to fix this behavior in the works, but since the problem is on the client side, the fix will only improve the situations for new versions of `cabal`. Happy New Years to all, and cheers to a very functional 2018, Gershom p.s.: since the problem comes in unpacking the 01-index.tar.gz into the 01-index.tar, you can also just untar that file in place manually, or force cabal into doing the same by running `touch ~/.cabal/packages/hackage.haskell.org/01-index.tar` ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
[Haskell] Announce: Haskell Platform 8.2.2
On behalf of the Haskell Platform team, I'm happy to announce the release of Haskell Platform 8.2.2 Now available at https://www.haskell.org/platform/ This includes GHC 8.2.2, cabal-install 2.0.0.1, and stack 1.6.1, all with many bugfixes since the last platform release. A full list of contents is available at https://www.haskell.org/platform/contents.html Thanks to all the contributors to this release, thanks to all the package and tool maintainers and authors, and a big thanks to the GHC team for all their hard work. There are currently no 32 bit Windows builds available. We expect to have those out in short order. A list of new GHC changes is available at: https://ghc.haskell.org/trac/ghc/blog/ghc-8.2.2-released A list of cabal changes is available at: https://hackage.haskell.org/package/cabal-install-2.0.0.1/changelog The cabal documentation page is at: https://www.haskell.org/cabal/users-guide/ A list of stack changes is at: https://docs.haskellstack.org/en/stable/ChangeLog/ The stack documentation page is at: https://docs.haskellstack.org/en/stable/README/ Happy Haskell Hacking all, Gershom ___ Haskell mailing list Haskell@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell
[Haskell-community] ANN: New Haskell.org Committee Members
Following the self-nomination period and discussion, the Haskell.org committee has selected the following members for a new three-year term, expiring 2020: * Tikhon Jelvis * Ryan Trinkle (reappointment) * George Wilson As per the rules of the committee, this discussion was held among the current members of the committee, and the outgoing members of the committee who were not seeking reappointment. Thank you to all the many candidates who submitted a self-nomination. We received a number of strong nominations. We would encourage all those who nominated themselves to consider self-nominating again in the future. The outgoing members are: John Wiegley and Alan Zimmerman. Thanks both for your service! Regards, Gershom ___ Haskell-community mailing list Haskell-community@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community
[Haskell] ANN: New Full Platform Build of Haskell Platform 8.2.1 for Mac
Thanks to some intrepid sleuthing by Albert Y. C. Lai, we realized there was a serious problem in the full (not core) builds of HP for Mac and Linux (not Windows). If you've seen lots of "unusable due to shadowed dependencies" errors on packages that came with full 8.2.1 platform installs on those systems, this is likely why. We should have tested better and caught this, and I'm sorry for the trouble it has caused. I've released a new build of the full mac installer, and updated the hash on the site. A new generic-linux build should follow soon. Regards, Gershom P.s. For those interested, the technical details are at https://github.com/haskell/haskell-platform/issues/285 -- in brief, the platform had done builds using inplace conf files but deployed using proper target package-conf files. This worked just fine until the new abi-depends machinery was introduced for better computing dependency mismatches (https://phabricator.haskell.org/D2846 is one place to start reading about that). That new machinery then recognized that different abis were generated for the inplace conf than the target conf, and things went screwy. But the problem here isn't with those changes -- it's with our inadequate testing that should have caught when things went wrong and alerted us that we needed to step back and fix things earlier, and the responsibility for that is all on me. ___ Haskell mailing list Haskell@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell
[Haskell] Announce: Haskell Platform 8.2.1
On behalf of the Haskell Platform team, I'm happy to announce the release of Haskell Platform 8.2.1 Now available at https://www.haskell.org/platform/ This includes GHC 8.2.1, cabal-install 2.0.0.0, and stack 1.5.1, all with many bugfixes and improvements since the last platform release. A full list of contents is available at https://www.haskell.org/platform/contents.html Thanks to all the contributors to this release, thanks to all the package and tool maintainers and authors, and a big thanks to the GHC team for all their hard work. Due to GHC bug #14081 (https://ghc.haskell.org/trac/ghc/ticket/14081), we do not have Win32 builds in this release. We anticipate resuming support for Win32 once the current issues with GHC on Win32 are fixed in the next release. A list of new GHC changes is available at: https://ghc.haskell.org/trac/ghc/blog/ghc-8.2.11-released A list of cabal changes is available at: https://hackage.haskell.org/package/cabal-install-2.0.0.0/changelog (note the support for the Backpack module system, as described at: https://github.com/ezyang/ghc-proposals/blob/backpack/proposals/-backpack.rst) The cabal documentation page is at: https://cabal.readthedocs.io/en/latest/ A list of stack changes is at: https://docs.haskellstack.org/en/stable/ChangeLog/ The stack documentation page is at: https://docs.haskellstack.org/en/stable/README/ Happy Haskell Hacking all, Gershom (Note -- one feature we still have not implemented yet for the platform but would like to is a generic linux installer that allows one to set a custom location and does not require root. Anyone who would like to volunteer to help with this, please get in touch!) ___ Haskell mailing list Haskell@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell
[Haskell] Announce: Haskell Platform 8.0.2-a builds for Windows 10 Creators Update
As many people know, the recent Windows 10 Creators Update broke the latest GHC 8.0.2 release. [1] We're happy to announce that there are now new 8.0.2-a builds on the Haskell Platform website that include the patch prepared by GHC HQ, and the hashes have been updated appropriately as well: https://www.haskell.org/platform/windows.html Note that this is not a new HP release in any official sense, nor are these new HP builds. These are the existing installers with the replacement of one file. Accordingly, they have new file names and hashes. However, all else remains the same. Similarly, no builds for other platforms have been updated. If you are not using Windows 10, this doesn't affect you in any way. And if you are, you probably already ran into this. Apologies for about a week of tardiness in getting this out, which is entirely due to my frazzledness. Happy Haskell Hacking all, Gershom [1] https://mail.haskell.org/pipermail/ghc-devs/2017-April/014131.html ___ Haskell mailing list Haskell@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell
[Haskell] ANN: Compose Unconference and Exchange [NYC, May 20-21]
I'm happy to announce that we now have a venue and dates for the affiliated Unconference and Exchange (aka "hackathon") for the Compose conference in NYC. It will take place the weekend immediately following the main conference, featuring improptu tutorials, collaborative coding, and generally be a good informal opportunity to work and discuss with functional programmers of all sorts. Registration (free) is at: https://www.eventbrite.com/e/cmpse-unconference-and-exchange-2017-tickets-33988530610 Registration for the main conference remains at: https://composeconference.eventbrite.com. Early bird tickets are now gone, so get tickets while you can! We're also happy to announce the topic of our invited keynote by Emily Riehl: A Categorical View of Computational Effects * Unconference information: http://www.composeconference.org/2017/unconference/ * Unconference registration: https://www.eventbrite.com/e/cmpse-unconference-and-exchange-2017-tickets-33988530610 * Full conference abstracts: http://www.composeconference.org/2017/program * Conference Registration: http://composeconference.eventbrite.com * Follow @composeconf on twitter for news: https://twitter.com/composeconf * On freenode irc, chat with fellow attendees at #composeconference * Corporate sponsorships are welcome. Current sponsors list forthcoming. * Policies (diversity and anti-harassment): http://www.composeconference.org/conduct * Email us with any questions at i...@composeconference.org * Please forward this announcement to interested parties and lists. ___ Haskell mailing list Haskell@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell
[Haskell] Compose Conference Call for Participation [NYC, May 18-19]
=== Call for Participation Compose Conference 2017 May 18-19 2017 New York, NY http://www.composeconference.org/2017 === The practice and craft of functional programming :: Conference Compose is a conference for typed functional programmers, focused specifically on Haskell, OCaml, F#, SML, and related technologies. Typed functional programming has been taken up widely, by industry and hobbyists alike. For many of us it has renewed our belief that code should be beautiful, and that programming can be as enjoyable as it is practical. Compose is about bringing together functional programmers of all levels of skill and experience — from technical leads to novices, and from long-time hackers to students just getting started. It will feature a keynote by Emily Riehl on aspects of category theory and computation, and two days of great talks. * Invited Talks Emily Riehl: TBA * Local Information (venue): http://www.composeconference.org/2017/ * Accepted Talks and Tutorials Barry Burd - Teaching Haskell David Rhodes - Learning F#: Case study with branch and bound Edmund Cape - Multiplying by 1 - an important form of computation and how it reveals distinctions between kleislis Enzo Alda, et al. - Reactive Sheets: an intuitive approach to functional‑reactive computing Hezekiah Carty and Chris Donaher - Distrest - REST access to distributed services Hongbo Zhang - BuckleScript: Making functional programming accessible to JavaScript developers Jennifer Paykin, Kenneth Foner, Antal Spector-Zabusky - `choose` Your Own Derivative Joachim Breitner - Lock-step simulation is child’s play Martín Ceresa, Gustavo Grieco - QuickFuzz Testing for Fun and Profit Michael Chavinda - Android programming in Froid Nikhil Barthwal - Implementing an Event-Driven Microservices Architecture in F#: A case study of Jet.com Nikita Volkov - New Hasql - a simpler, safer and faster Postgres client Sebastien Mondet - Typed-Tagless Final Bioinformatics Stephen Compall - Working with Monads in OCaml Stuart Popejoy - Smart Contracts and Formal Verification with Z3 with Pact Tikhon Jelvis - The Probability Monad Yaron Minsky - Data Driven UIs, Incrementally * Full abstracts: http://www.composeconference.org/2017/program * Registration: http://composeconference.eventbrite.com * Follow @composeconf on twitter for news: https://twitter.com/composeconf * On freenode irc, chat with fellow attendees at #composeconference * Corporate sponsorships are welcome. Current sponsors list forthcoming. * Policies (diversity and anti-harassment): http://www.composeconference.org/conduct * Email us with any questions at i...@composeconference.org * Please forward this announcement to interested parties and lists. ___ Haskell mailing list Haskell@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell
[Haskell] Announce: Haskell Platform 8.0.2
On behalf of the Haskell Platform team, I'm happy to announce the release of Haskell Platform 8.0.2 Now available at https://www.haskell.org/platform/ This includes GHC 8.0.2, cabal-install 1.24.0.2, and stack 1.3.2, all with many bugfixes and improvements since the last platform release. This platform release we've cleaned up the webpage a bit, and renamed the "minimal" distribution to the "core" distribution to highlight that it is the recommended approach (and simplified the accompanying text). A number of improvements have been made to the windows installer -- notably the /S option for silent install is now in fully working order, and we have the flags /STACK and /D (for stack and platform-ghc install paths). The installer expects no quoting of paths, even with spaces within the paths, like so: HaskellPlatform-8.0.2-full-x86_64-setup.exe /S /STACK=c:\My install path for stack\local\bin /D=c:\program files\Haskell\Platform\8.0.2 There is also an updated version of msys2 included, which includes pacman, et al. to ease the installation of libraries with more complex foreign dependencies. Changes to Contents: * As a result of transitive dependencies of platform packages, the integer-logarithms and call-stack packages have been added to the full platform. A full list of contents is available at https://www.haskell.org/platform/contents.html Thanks to all the contributors to this release, thanks to all the package and tool maintainers and authors, and a big thanks to the GHC team for all their hard work. A list of new GHC changes is available at: https://ghc.haskell.org/trac/ghc/blog/ghc-8.0.2-released A list of cabal changes is available at: https://hackage.haskell.org/package/cabal-install-1.24.0.2/changelog The new cabal documentation page is at: https://cabal.readthedocs.io/en/latest/ A list of stack changes is at: https://docs.haskellstack.org/en/stable/ChangeLog/ Happy Haskell Hacking all, Gershom (Note -- one feature we have not implemented yet for the platform but would like to is a generic linux installer that allows one to set a custom location and does not require root. Anyone who would like to volunteer to help with this, please get in touch!) ___ Haskell mailing list Haskell@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell
Re: Narrower (per-method) GND
Richard — your idea is really interesting. How would the dreaded role restriction have to be modified to detect and allow this sort of granularity? —g On January 9, 2017 at 1:34:17 PM, Richard Eisenberg (r...@cs.brynmawr.edu) wrote: > I agree with David that using explicit `coerce`s can be quite verbose and may > need ScopedTypeVariables > and InstanceSigs. But visible type application should always work, because > class methods > always have a fixed type argument order. Regardless, requiring users to do > all this for > GND on Monad would be frustrating. > > Actually, I just had an insight about this: there is no reason to use one > deriving strategy > for all methods in an instance. I can think of 4 ways to fill in the > implementation of a class > method in an instance: > > 1. Explicit, hand-written implementation > 2. Defaulting to the implementation written in the class (or `error > "undefined method"` > in the absence of a default. This is essentially the default default.) > 3. Stock implementation provided by GHC > 4. Coerce > > Ways 2, 3, and 4 all have extra restrictions: Way 2 might have extra type > constraints due > to a `default` signature. Way 3 restricts the choice of class and type. Way 4 > works only > on newtypes and then imposes role restrictions on the method's type. > > GHC provides a `deriving` mechanism so that you can request Way 2 > (`default`), 3 (`stock`), > or 4 (`newtype`) to fill in every method in a class. But there's no need to > provide this > feature at such a course granularity. What about: > > > newtype N a = MkN (Foo a) > > instance Blah a => C (N a) where > > meth1 = ... > > deriving default meth2 -- a bit silly really, as you can just leave meth2 > > out > > deriving stock meth3 -- also silly, as C isn't a stock class, but you get > > the idea > > deriving newtype meth4 > > We could also imagine > > > deriving newtype instance Blah a => Monad (N a) where > > deriving default join -- not so silly anymore! > > This syntax allows a `where` clause on standalone deriving allowing you to > override > the overall `deriving` behavior on a per-method basis. > > I actually quite like this extension... > > Richard > > > > On Jan 8, 2017, at 11:54 PM, David Feuer wrote: > > > > You *can* do this, but it's often not so concise. When the type constructor > > has parameters, > you need to pin them down using ScopedTypeVariables. So you end up needing to > give a signature > for the method type in order to bring into scope variables you then use in > the argument > to coerce. If you have > > > > newtype Foo f a = Foo (Foo f a) > > > > then you may need > > > > instance Bar f => Bar (Foo f) where > > bah = coerce (bah @ f @ a) > > :: forall a . C a => ... > > > > to pin down the C instance. > > > > If you don't want to use explicit type application (e.g., you're using a > > library that > does not claim to have stable type argument order), things get even more > verbose. > > > > On Jan 8, 2017 11:32 PM, "Joachim Breitner" > > wrote: > > Hi, > > > > just responding to this one aspect: > > > > Am Sonntag, den 08.01.2017, 21:16 -0500 schrieb David Feuer: > > > but using defaults for > > > the others would give poor implementations. To cover this case, I > > > think it would be nice to add per-method GND-deriving syntax. This > > > could look something like > > > > > > instance C T where > > > deriving f > > > g = > > > > Assuming > > newtype T = MkT S > > > > You can achieve this using > > > > instance C T where > > f = coerce (f @F) > > g = > > > > (which is precisely what GND does), so I don’t think any new syntax is > > needed here. > > > > 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 > > ___ > > Glasgow-haskell-users mailing list > > Glasgow-haskell-users@haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users > > > > > ___ > > Glasgow-haskell-users mailing list > > Glasgow-haskell-users@haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users > > ___ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users > ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: [Haskell] [Haskell-community] Call for Haskell.org Committee Nominations
We're starting the discussion now. Ideally we'll wrap it up within seven days or so. --Gershom On Mon, Dec 5, 2016 at 4:54 PM, Noon van der Silk <noonsli...@gmail.com> wrote: > Out of interest, when will the new committee members be announced? > > On Sat, Nov 12, 2016 at 9:29 AM, Gershom B <gersh...@gmail.com> wrote: >> >> Dear Haskellers, >> >> It is time to put out a call for new nominations (typically but not >> necessarily self-nominations) to the haskell.org committee. We have >> four members of our committee due for retirement -- Adam Foltzer, >> Nicolas Wu, Andres Loeh, and Edward Kmett (who is stepping down >> early). As per our bylaws, three of the slots will be for regular >> three year terms, and one will be a short one year term to fill out >> the remainder of Edward's. >> >> To nominate yourself, please send an email to committee at haskell.org >> by December 2, 2016. The retiring members are eligible to re-nominate >> themselves. Please feel free to include any information about yourself >> that you think will help us to make a decision. >> >> The Haskell.org committee serves as a board of directors for >> Haskell.org, a 501(c)3 nonprofit which oversees technical and >> financial resources related to Haskell community infrastructure. >> >> Being a member of the committee does not necessarily require a >> significant amount of time, but committee members should aim to be >> responsive during discussions when the committee is called upon to >> make a decision. Strong leadership, communication, and judgement are >> very important characteristics for committee members. The role is >> about setting policy, providing direction/guidance for Haskell.org >> infrastructure, planning for the long term, and being fiscally >> responsible with the Haskell.org funds (and donations). As overseers >> for policy regarding the open source side of Haskell, committee >> members must also be able to set aside personal or business related >> bias and make decisions with the good of the open source Haskell >> community in mind. >> >> We seek a broad representation from different segments of the Haskell >> world -- including but not limited to those focused on education, >> those focused on industrial applications, those with background in >> organizing users-groups, and those focused directly on our technical >> infrastructure. >> >> More details about the committee's roles and responsibilities are on >> >> https://wiki.haskell.org/Haskell.org_committee >> >> If you have any questions about the process, please feel free to >> e-mail us at committee at haskell.org, or contact one of us >> individually. >> >> Best, >> Gershom Bazerman >> ___ >> Haskell-community mailing list >> haskell-commun...@haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community > > > > > -- > Noon Silk, ن > > https://silky.github.io/ > > "Every morning when I wake up, I experience an exquisite joy — the joy > of being this signature." ___ Haskell mailing list Haskell@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell
Re: [Haskell-community] haskell.org download page
As an update, the "getting started" section has not been worked on sufficiently as of yet. However, we have an upcoming platform and ghc release again, and as the os x and windows minimal installers remain out-of-date (and increasingly broken) I've taken the "minimal" (pardon the pun) step of trying to leave nearly everything as is but pointing the downloads there to minimal "via the platform" rather than via the outdated methods. I know this is not where we hoped to be yet, but its a small stopgap step that i hope people can be ok with while other things get sorted out. Thanks everyone for their patience and understanding. Best, Gershom On Thu, Sep 1, 2016 at 5:20 AM, Friedrich Wiemer <friedrichwie...@gmail.com> wrote: > +1 from me, too. > > On 01.09.2016 09:41, John Wiegley wrote: >>>>>>> "GB" == Gershom B <gersh...@gmail.com> writes: >> >> GB> I think this is a very good point being made. We should disengangle the >> GB> installer question from the “getting started” question. Someone on >> reddit >> GB> even proposed having two seperate pages entirely. >> >> GB> (Again, I give the caveat I’m speaking just for myself here, and thinking >> GB> this through as an idea I’d like to hear others’ thoughts on). >> >> Yes, I also think this is a great idea! +1 >> > > > ___ > Haskell-community mailing list > Haskell-community@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community > ___ Haskell-community mailing list Haskell-community@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community
[Haskell] Call for Haskell.org Committee Nominations
Dear Haskellers, It is time to put out a call for new nominations (typically but not necessarily self-nominations) to the haskell.org committee. We have four members of our committee due for retirement -- Adam Foltzer, Nicolas Wu, Andres Loeh, and Edward Kmett (who is stepping down early). As per our bylaws, three of the slots will be for regular three year terms, and one will be a short one year term to fill out the remainder of Edward's. To nominate yourself, please send an email to committee at haskell.org by December 2, 2016. The retiring members are eligible to re-nominate themselves. Please feel free to include any information about yourself that you think will help us to make a decision. The Haskell.org committee serves as a board of directors for Haskell.org, a 501(c)3 nonprofit which oversees technical and financial resources related to Haskell community infrastructure. Being a member of the committee does not necessarily require a significant amount of time, but committee members should aim to be responsive during discussions when the committee is called upon to make a decision. Strong leadership, communication, and judgement are very important characteristics for committee members. The role is about setting policy, providing direction/guidance for Haskell.org infrastructure, planning for the long term, and being fiscally responsible with the Haskell.org funds (and donations). As overseers for policy regarding the open source side of Haskell, committee members must also be able to set aside personal or business related bias and make decisions with the good of the open source Haskell community in mind. We seek a broad representation from different segments of the Haskell world -- including but not limited to those focused on education, those focused on industrial applications, those with background in organizing users-groups, and those focused directly on our technical infrastructure. More details about the committee's roles and responsibilities are on https://wiki.haskell.org/Haskell.org_committee If you have any questions about the process, please feel free to e-mail us at committee at haskell.org, or contact one of us individually. Best, Gershom Bazerman ___ Haskell mailing list Haskell@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell
[Haskell-community] Haskell Wiki and Infra
(changing the subject line to reflect this thread) On September 1, 2016 at 7:48:46 PM, Patrick Pelletier (c...@funwithsoftware.org) wrote: > > In that vein, is there a place to file bugs against HaskellWiki? Or is > that one of the areas in need of a volunteer? My own personal itch I'd > like to scratch is the lack of diffs on the wiki: > > https://mail.haskell.org/pipermail/haskell-cafe/2016-April/123701.html > > Many thanks to the Haskell Committee, to FP Complete, and to all of the > volunteers who work on Haskell! For issues with the haskell wiki as well as all other infrastructure problems in general, the ad...@haskell.org mail alias hits a group of infra maintainers. A github tracker that’s more widely advertised as well might not be a bad idea, since its become so standard. Over the years our current infra/ops team has gotten rather busy in other arenas, so we could use volunteers nearly everywhere (anyone with any sysadmin experience, even if just on a personal box, and who feels they’ll have ongoing time to donate, please email me! and again, anyone who can help deal with mail stuff would be especially appreciated at this moment). We keep things humming, but haven’t really freed up the time to tackle much in the way of pushing things forward. But you’re correct that the wiki could absolutely use a volunteer. I made a bit of an effort last year to get things rolling, but it stalled out pretty quickly (https://mail.haskell.org/pipermail/haskell-cafe/2015-April/119219.html). Perhaps the call was too ambitious and people didn’t know where to start. Maybe it just needed more energy and will to drive it than any of us had in supply at the moment. We _did_ get a team of people approving new accounts instead of just one overworked individual. (Thank you to all who have done that and continue to! It irks me that we need such a manual process, but the waves of spam we got before periodically despite our capcha efforts were far worse). I can’t quite infer from your message if you are volunteering yourself. If you are, thank you so much for your offer! Please email me and we’ll coordinate how to get you the right login credentials, etc. Best, Gershom (Note, by the way, those who may be hesitant to volunteer not out of lack of time or desire to help, but out of fear you don’t have enough experience or knowledge — most admin work [to be honest like most programming] isn’t knowing what to do right away, but instead about knowing some desired end goal, and then being willing to wade through a bunch of searching and documentation to come up with a plan, talking it over with folks, perhaps experimenting a bit, and eventually finally knowing what to do. And, of course, knowing which experiments are irreversable and shouldn’t be conducted :-). And the hardest step usually isn’t in fixing any problem, but in making the mental leap from “this is a problem someone should fix” to “this is a problem I will fix”.) ___ Haskell-community mailing list Haskell-community@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community
Re: [Haskell-community] haskell.org download page
And... before I had the chance to pull something together, someone else jumped in and made this very nice proposal on the website tracker: https://github.com/haskell-infra/hl/issues/176 That seems like a good basis for discussion :-) (Note that this presupposes is to renaming minimal to the Haskell Toolchain, as per the discussion at https://github.com/haskell/haskell-platform/issues/250) --Gershom On Tue, Aug 30, 2016 at 9:17 AM, Gershom B <gersh...@gmail.com> wrote: > On August 30, 2016 at 6:23:36 AM, Simon Marlow (marlo...@gmail.com) wrote: >> > Can't we get rid of HP Full? I don't see a use for that any more. > > I think it can be removed from a prominent spot in the downloads page. There > are a variety of cases where people still seem to prefer it for some settings > (especially those which may have limited ongoing network access), despite > being warned that it is not typically recommended, so I think it makes sense > to continue to provide it in some fashon, albeit less prominent, for the time > being. > > If I can scrape the time together today I’ll try to pull together some text > for the whole downloads page to propose here for feedback, trying to take > this discussion into account. > > —Gershom ___ Haskell-community mailing list Haskell-community@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community
Re: [Haskell-community] Is it reasonable to poll the community on this ML?
On August 29, 2016 at 11:15:19 AM, Paolo Giarrusso (paolo.giarru...@uni-tuebingen.de) wrote: > If the poll was announced there, there would still be extra friction. > But IIUC only the mailing list was announced there. There is no poll. There is a modest discussion kicked off by Jason Dagit (who used to serve on the committee, but has not been on it for some time now) about a modest change (at this point swapping the bitrotted minimal installers for the HP minimal installers which are current). The committee does not operate by poll, it operates on the basis of broad discussion (with this list being the preferred venue) and then making choices amongst committee members as informed by that discussion. This is laid out at https://wiki.haskell.org/Haskell.org_committee > I might understand the concern about archiving, but haskell-cafe > solves that. And "the committee can't be expected to follow > discussions" and "is empowered to act" does sound like "the committee > can't be expected to listen to the community”. It means that committee members should be expected to chase all over social media and sort through lots of poor signal/noise ratio to find potentially relevant discussions at all times. Rather, it is better to centralize these things to the extent possible.That’s all. —gershom ___ Haskell-community mailing list Haskell-community@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community
Re: Proposal process status
On July 21, 2016 at 8:51:15 AM, Yuras Shumovich (shumovi...@gmail.com) wrote: > > I think it is what the process should change. It makes sense to have > two committees only if we have multiple language implementations, but > it is not the case. Prime committee may accept or reject e.g. GADTs, > but it will change nothing because people will continue using GADTs > regardless, and any feature accepted by the Prime committee will > necessary be compatible with GADTs extension. I disagree. By the stated goals of the H2020 Committee, if it is successful, then by 2020 it will still for the most part have only standardized ony a _portion_ of the extentions that now exist today. There’s always been a barrier between implementation and standard in the Haskell language, that’s precisely one of the things that _keeps_ it from having become entirely implementation-defined despite the prevelance of extensions. Having two entirely different processes here (though obviously not without communication between the individuals involved) helps maintain that. —Gershom ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: Simon's email classified as spam
Dear all, thanks for the many responses. It appears that this is now fixed. (no need to send more). Cheers, Gershom On June 19, 2016 at 3:08:28 PM, Simon Peyton Jones via Glasgow-haskell-users (glasgow-haskell-users@haskell.org) wrote: > Dear GHC devs/users > This is another test to see if email from me, relayed via Haskell.org, ends > up in your spam > folder. Gershom thinks he’s fixed it (below). Can I trespass on your patience > once more? > Just let me know if this email ends up in your inbox or spam. Can you cc John > and Gershom (but > perhaps not everyone else)? Thanks > Simon > > > | From: Gershom B [mailto:gersh...@gmail.com] > > | Sent: 18 June 2016 18:53 > > | To: Simon Peyton Jones ; John Wiegley > > | > > | Cc: Michael Burge > > | Subject: Re: FW: CMM-to-SAM: Register allocation weirdness > > | > > | Simon — I just found two possible sources of the problem (first: the top > > | level config didn’t take hold due to other errors when updating — fixed > that, > > | and second, it might be possible the top level config isn’t retroactively > > | applied to all lists — so i added the config to the relevant lists > directly). > > | > > | I think if you try one more time it might work (fingers crossed). > > ___ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users > ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
[Haskell] Announce: Haskell Platform 8.0.1
On behalf of the Haskell Platform team, I'm happy to announce the release of Haskell Platform 8.0.1 Now available at https://www.haskell.org/platform/ This platform includes features initially planned in the "Improving the 'Get Haskell Experience'" proposal of June 2015. [1] * Minimal as well as Full distributions. The minimal distribution only includes GHC core libraries as well as additional tools. This is now the recommended distribution. The Full distribution remains an option for those who want a one-step installer with the broader set of platform libraries preinstalled. * Inclusion of the Stack tool for developing Haskell projects [2] Other highlights of this release include the following * The new cabal 1.24 including the great "new-build" tech preview of nix-like build dependency management [3] * On windows, a cabal/msys setup that allows packages such as "network" to build "out of the box". (almost*) * At long last, prebuilt Linux 32 bit platform installers Changes to Contents: * Some packages have been removed from the installed packages set (both minimal and full) including old-locale, old-time, cgi, and the transitive cgi dependencies: transformers-compat, multipart, and exceptions. * fixed has been added to the platform as a transitive dependency of GLUT. A full list of contents is available at https://www.haskell.org/platform/contents.html Thanks to all the contributors to this release, thanks to all the package and tool maintainers and authors, and a big thanks to the GHC team for putting together such an exciting new compiler release! A fuller list of new GHC changes is available at: https://mail.haskell.org/pipermail/ghc-devs/2016-May/012098.html A fuller list of new cabal changes is available at: http://coldwa.st/e/blog/2016-05-04-Cabal-1-24.html Happy Haskell Hacking all, Gershom [1] http://projects.haskell.org/pipermail/haskell-platform/2015-July/003129.html [2] http://haskellstack.org [3] http://blog.ezyang.com/2016/05/announcing-cabal-new-build-nix-style-local-builds/ * To build "network" and other msys-dependent packages on windows, you will need to augment your cabal config file with the following lines: extra-prog-path: C:\Program Files\Haskell Platform\8.0.1\msys\usr\bin extra-lib-dirs: C:\Program Files\Haskell Platform\8.0.1\mingw\lib extra-include-dirs: C:\Program Files\Haskell Platform\8.0.1\mingw\include ___ Haskell mailing list Haskell@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell
Re: Scope of committee (can we do *new* things?)
On May 8, 2016 at 9:25:33 PM, Richard Eisenberg (e...@cis.upenn.edu) wrote: > > I do absolutely think we should be cautious about addressing unimplemented > behavior. > I would be strongly against a new type-system extension that hasn't been > field-tested. > However, I do think pondering lexical/parsical changes (such as limber > separators) > should be considered in scope. While such changes should definitely be in scope, I do think that the proper mechanism would be to garner enough interest to get a patch into GHC (whether through discussion on the -prime list or elsewhere) and have an experimental implementation, even for syntax changes, before such proposals are considered ready for acceptance into a standard as such. But I also agree that discussion of things which may be in the pre-implementation phase are in scope — just that the next step is to get them past that phase before they’re considered for inclusion as such. There are enough traps in parsing that specification without an implementation is always a risky choice. Recall for example the case of fixity resolution, finally fixed in Haskell2010 (https://prime.haskell.org/wiki/FixityResolution) where the behavior in the report was at variance with all implementations. I would hope that if a segment of the prime committee wants to test-run an experimental syntax feature, then this would take sufficient precedence over concerns regarding “language fragmentation” that the GHC team would be open to guarding it behind a flag. Given the number of GHC developers involved in this effort, I think that’s not a bad estimation :-) Cheers, Gershom ___ Haskell-prime mailing list Haskell-prime@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
Re: The GADT debate
On May 7, 2016 at 10:30:05 PM, wren romano (w...@community.haskell.org) wrote: > Hi all, > > There's been some discussion about whether to consider including GADTs > in the new report, but it's been mixed up with other stuff in the > thread on incorporating extensions wholesale, which has unfortunately > preempted/preceded the discussion about how to go about having such > discussions(!). > > My position on the debate is that we should avoid having the debate, > just yet. (Which I intended but failed to get across in the email > which unintentionally started this all off.) I think we have many much > lower-hanging fruit and it'd be a better use of our time to try and > get those squared away first. Doing so will help us figure out and > debug the process for having such debates, which should help the GADT > debate itself actually be fruitful. As well as making progress on > other fronts, so we don't get mired down first thing. Thanks for this summary Wren. Let me add something I would be interested in seeing happen in the “meantime” — an attempt (orthogonal to the prime committee at first) to specify an algorithm for inference that is easier to describe and implement than OutsideIn, and which is strictly less powerful. (And indeed whose specification can be given in a page or two of the report). A compliant compiler could then be required to have inference “at least” that good, but also be allowed to go “above and beyond”. Thus fully portable H2020 code might require more specified signatures than we need in GHC proper, but all such code would also typecheck in GHC. It seems to me that the creation of such an algorithm might be an interesting bit of research in itself. —Gershom ___ Haskell-prime mailing list Haskell-prime@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
Re: Are there GHC extensions we'd like to incorporate wholesale?
I agree that GHC extensions should be the starting point for new additions, as changes to the report should be based on established implementations (to ensure that changes are implementable and to ensure that they work out well for users). 1) background reading There were a few interesting threads on reddit the other day that may provide some fodder to think about. First, there was a survey of what extensions that people found useful and would like incorporated, as well as their concerns: https://www.reddit.com/r/haskell/comments/4fsuvu/can_we_have_xhaskell2016_which_turns_on_the_most/ (Feel free to disregard the confusion of how they described “Haskell2016” and the like for something closer to glasgow-exts-2016, as its extraneous to what makes this interesting). Second, the summary thread on the results: https://www.reddit.com/r/haskell/comments/4ggp8z/summary_of_the_xhaskell2016_feedback/ The summary results give a good indication of what extensions there might seem to be the most widespread sentiment to standardize. This thread also gives a link to Reid Barton’s lovely example of how FlexibleInstances can be used to violate coherence: https://www.reddit.com/r/haskell/comments/2agy14/type_classes_confluence_coherence_global/civ6y1g The same trick is supposed to apply to MPTCs. (In both cases, I imagine there can be a “fixup” that would prevent this, but that’s for another discussion). 2) suggestions for proceeding In any case, it seems to me (as a non-prime-committee member) that it would be good to proceed in two parallel tracks. First: A victim^H^H^H^H^H^H volunteer to pick a particularly low-hanging fruit (lambdacase, tuple sections, binary literals) and try to do a test-run of the proposal process to work out the kinks and set an example for others to follow. Perhaps a few could be worked on by different people at once. (As a datapoint, here is I think how an accepted proposal looked under the H2010 process: https://prime.haskell.org/wiki/NoNPlusKPatterns) (And I see that Austin has already volunteered! wonderful!) Second: Some high-level effort to categorize and pull together a dependency graph of the other extensions. A googledoc spreadsheet or a trello board might be a good “work arena” for this. I would want to separate extensions into for example buckets like “pure syntax” “typeclass related” “monad syntax” “deriving related” “higher-rank related” “record related” “concurrency related”. The idea would be that things in the same bucket would have a higher chance of interacting / potentially needing to be treated in tandem. That way, areas could be tackled at once, and the committee could “burndown” easy stuff, while perhaps individuals with expertise might want to try to work on the side to find “minimal, safe” paths through the thicket of complex extensions. (standardizing GADT syntax without yet adding type equality constraints to enable actual GADTs is a good example here. Another _might_ be for example allowing RankNTypes but specifying that compliant compilers need only accept such type signatures fully specified, but could optionally go above and beyond in inference, etc). Note that more complex proposals could always be worked out by interest groups working by themselves, and only presented to a larger audience once some kinks were ironed out, etc. Cheers, Gershom On May 2, 2016 at 6:57:46 PM, John Wiegley (jo...@newartisans.com) wrote: > I wonder if there are GHC extensions we'd like to promote as features in the > next report, as a starting point for discussing new additions. > > There are a few GHC features that have become part of the regular Haskell > landscape, such that it's hard to imagine a modern Haskell without them. For > example, MultiParamTypeClasses, OverloadedStrings, GADTs, TypeFamilies, etc. > > How much "work" is typically involved in promoting a feature to be in the > Report, and how do we determine when it's a bad idea? > > -- > John Wiegley GPG fingerprint = 4710 CF98 AF9B 327B B80F > http://newartisans.com 60E1 46C4 BD1A 7AC1 4BA2 > ___ > 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] Summer of Haskell - Now Accepting Applications!
(Note: I am posting this on behalf of Edward Kmett who has spotty availability at the moment) We've posted an official Summer of Haskell website: https://summer.haskell.org/ It contains the full timeline for the program this summer, and most importantly, a form for submitting student applications, also linked here: https://docs.google.com/forms/d/1JLIa58u7AcWN31bH_LcCBujN9uzAwfd3HxrT32qz9_g/viewform The student application period ends next Friday, May 6. Last year we had a very successful project brainstorming thread. This led to our largest and most successful Summer of Code, ever. There is a thread on reddit now devoted to the purpose of further brainstorming for this year: https://www.reddit.com/r/haskell/comments/4gh1tu/summer_of_haskell_now_accepting_applications/ If you have a proposal that you think a student could make a good dent in over the course of a summer, especially one with broad impact on the community, please feel free to discuss it there. If you are a potential student, please feel free to skim the proposals for ideas, or put forth ones of your own! If you are a potential mentor, please feel free to comment on proposals that interest you, put forth ideas looking for students and express your interest, to help us pair up potential students with potential mentors. Ultimately, the project proposals that are submitted get written by students, but if we can give a good sense of direction for what the community wants out of the summer, we can improve the quality of proposals, and we can recruit good mentors to work with good students on good projects. Resources: We have a wiki on https://ghc.haskell.org/trac/summer-of-code/ It is, of course, a Wiki, so if you see something out of order, take a whack at fixing it. We have an active #haskell-gsoc channel on irc.freenode.net that we run throughout the summer. Potential mentors and students alike are welcome. We have a Trac full of suggested Google Summer of Code proposals both current and from years past, but it could use a whole lot of eyeballs and an infusion of fresh ideas: https://ghc.haskell.org/trac/summer-of-code/report/1 Many of our best proposals in years have come from lists of project suggestions that others have blogged about. Many of our best students decided to join the summer of code based on these posts. The Trac isn't the only source of information on interesting projects, and I'd encourage folks to continue posting their ideas. If you or your employer would be interested in helping to fund additional students, please feel free to reach out to me. Thank you, -Edward Kmett ___ Haskell mailing list Haskell@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell
[Haskell-community] addition of http://www.happylearnhaskelltutorial.com/ to haskell website resources?
There’s been a pull request open to add http://www.happylearnhaskelltutorial.com/ to the website under /documentation I haven’t read it myself all the way through. It does look like it has developed a fair amount of material by now. Do people think it should be added as a tutorial? —Gershom ___ Haskell-community mailing list Haskell-community@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community
Re: Warnings, -Wall, and versioning policy
On Wed, Jan 13, 2016 at 7:43 AM, Simon Peyton Jones
<simo...@microsoft.com> wrote:
> An implication is that GHC is free to introduce new warnings X into -Wall.
> Indeed doing so would be good, because the warning X might later move into
> the default set. Indeed for such warnings, adding a "PS: this warning will
> become the default in GHC 9.2" might be a useful way to signal the upcoming
> change. Then you can use -Wall and look for any "PS" indicators.
Yep. In general I think we don't know how _much_ noise a warning will
create until it makes it into the wild, so just as with other new
features its good to give them a bit of a "dry run" before deciding
that they come "by default."
> You don’t give a rationale for (2) but I think you intend that if someone
> wants to add -Wno-X when GHC introduces X in 9.0, you don't want GHC 8.6 to
> fall over. Worth articulating the rationale.
Yes, that's exactly the rationale. It doesn't help us short term, but
longer term it should let users fiddle with warning flags more freely.
I think the general issue with three releases is not whether or not
GHC introduces warnings and at what pace, but that certain _types_ of
warnings (in particular redundancies, be they constraints, imports,
etc) will fire on entirely desirable code due to certain migration
paths. Most of the tricks we developed for backwards-compatible
migrations essentially depend on certain redundancies in code for a
period. Those can't be removed without hurting backwards-compatibility
of code, but their presence also induces warnings.
So as a whole "warning freeness" and "backwards compatible migrations"
become increasingly at odds with one another.
A full refactor of our warning sets would probably help in this
regard, so that the default advice could be "good code is -Wlint clean
but not necessarily -Wpedantic clean". Or even "is clean under
-Wpedantic -Wno-redundancies".
--Gershom
>
> | -Original Message-
> | From: Glasgow-haskell-users [mailto:glasgow-haskell-users-
> | boun...@haskell.org] On Behalf Of Gershom B
> | Sent: 13 January 2016 02:20
> | To: GHC users <glasgow-haskell-users@haskell.org>; ghc-d...@haskell.org;
> | Edward Kmett <ekm...@gmail.com>; Herbert Valerio Riedel <h...@gnu.org>;
> Simon
> | Marlow <marlo...@gmail.com>
> | Subject: Re: Warnings, -Wall, and versioning policy
> |
> | Hi Simon. I think you raise important issues here, although I believe you’re
> | mistaken in one regard. Hackage rejects -Werror but I don’t think it rejects
> | -Wall.
> |
> | What I’d suggest is perhaps the following.
> |
> | 1) The libraries committee put forward -Wall cleanliness as an _aspirational
> | goal_ rather than a final product, noting that the actual cleanliness might
> | be with regards to `-Wall -Wno-foo -Wno-bar``.
> |
> | 2) GHC _change its code_ so that `ghc -Wno-wat` yields a _warning_ rather
> | than an _error_ on `-W` followed by an unrecognized string.
> |
> | 3) No warning flags be introduced into the _default_ set without at least a
> | few releases in some other set such as `-Wall`.
> |
> | We may also want to try to maintain a “best practices” example cabal file
> | that shows how one can build with additional warnings under a “dev” flag,
> and
> | with fewer warnings otherwise — so that the noise inflicted on package devs
> | under their builds doesn’t get inflicted on all end users, and even perhaps
> | with different warning flags per ghc version flag.
> |
> | I think this will respect the concerns of people that like to use `-Wall`,
> | want to have relatively warning clean code, and want to have some degree of
> | backwards compatibility (which is not an unreasonable combination in my
> | opinion).
> |
> | Some related
> | discussion: https://ghc.haskell.org/trac/ghc/ticket/11370 and
> https://ghc.has
> | kell.org/trac/ghc/wiki/Design/Warnings
> |
> | Cheers,
> | Gershom
> |
> |
> | On January 12, 2016 at 11:18:57 AM, Simon Marlow (marlo...@gmail.com) wrote:
> | > Hi folks,
> | >
> | > We haven't described what guarantees GHC provides with respect to -Wall
> | > behaviour across versions, and as a result there are some differing
> | > expectations around this. It came up in this weeks' GHC meeting, so we
> | > thought it would be a good idea to state the policy explicitly. Here it
> is:
> | >
> | > We guarantee that code that compiles with no warnings with -Wall
> | > ("Wall-clean") and a particular GHC version, on a particular
> | > platform, will be Wall-clean with future minor releases of the same
> | > major GHC version on the same platform.
> | >
> | > (we plan to p
Re: Warnings, -Wall, and versioning policy
Hi Simon. I think you raise important issues here, although I believe you’re
mistaken in one regard. Hackage rejects -Werror but I don’t think it rejects
-Wall.
What I’d suggest is perhaps the following.
1) The libraries committee put forward -Wall cleanliness as an _aspirational
goal_ rather than a final product, noting that the actual cleanliness might be
with regards to `-Wall -Wno-foo -Wno-bar``.
2) GHC _change its code_ so that `ghc -Wno-wat` yields a _warning_ rather than
an _error_ on `-W` followed by an unrecognized string.
3) No warning flags be introduced into the _default_ set without at least a few
releases in some other set such as `-Wall`.
We may also want to try to maintain a “best practices” example cabal file that
shows how one can build with additional warnings under a “dev” flag, and with
fewer warnings otherwise — so that the noise inflicted on package devs under
their builds doesn’t get inflicted on all end users, and even perhaps with
different warning flags per ghc version flag.
I think this will respect the concerns of people that like to use `-Wall`, want
to have relatively warning clean code, and want to have some degree of
backwards compatibility (which is not an unreasonable combination in my
opinion).
Some related discussion: https://ghc.haskell.org/trac/ghc/ticket/11370 and
https://ghc.haskell.org/trac/ghc/wiki/Design/Warnings
Cheers,
Gershom
On January 12, 2016 at 11:18:57 AM, Simon Marlow (marlo...@gmail.com) wrote:
> Hi folks,
>
> We haven't described what guarantees GHC provides with respect to -Wall
> behaviour across versions, and as a result there are some differing
> expectations around this. It came up in this weeks' GHC meeting, so we
> thought it would be a good idea to state the policy explicitly. Here it is:
>
> We guarantee that code that compiles with no warnings with -Wall
> ("Wall-clean") and a particular GHC version, on a particular
> platform, will be Wall-clean with future minor releases of the same
> major GHC version on the same platform.
>
> (we plan to put this text in the User's Guide for future releases)
>
> There are no other guarantees. In particular:
> - In a new major release, GHC may introduce new warnings into -Wall,
> and/or change the meaning of existing warnings such that they trigger
> (or not) under different conditions.
> - GHC may generate different warnings on different platforms. (examples
> of this are -fwarn-overflowed-literals and
> -fwarn-unsupported-calling-conventions)
>
> Some rationale:
> - We consider any change to the language that GHC accepts to be a
> potentially code-breaking change, and subject to careful scrutiny. To
> extend this to warnings would be a *lot* of work, and would make it
> really difficult to introduce new warnings and improve the existing ones.
> - Warnings can be based on analyses that can change in accuracy over
> time. The -fwarn-unused-imports warning has changed a lot in what it
> rejects, for example.
> - We often introduce new warnings that naturally belong in -Wall. If
> -Wall was required to be a fixed point, we would have to start
> introducing new flags, and versioning, etc. and even keep the old
> implementation of warnings when they change. It would get really messy.
>
> There are some consequences to this. -Wall -Werror is useful for
> keeping your code warning-clean when developing, but shipping code with
> these options turned on in the build system is asking for trouble when
> building your code with different GHC versions and platforms. Keep
> those options for development only. Hackage already rejects packages
> that include -Wall for this reason.
>
> One reason we're raising this now is that it causes problems for the
> 3-release policy
> (https://prime.haskell.org/wiki/Libraries/3-Release-Policy) which
> requires that it be possible to write code that is Wall-clean with 3
> major releases of GHC. GHC itself doesn't guarantee this, so it might
> be hard for the core libraries committee to provide this guarantee. I
> suggest this requirement be dropped from the policy.
>
> Cheers,
> Simon
> ___
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
[Haskell] ANNOUNCE: Haskell Platform 7.10.3
Haskellers, we are pleased to announce the release of Haskell Platform 7.10.3 * * get it here: https://www.haskell.org/platform/ * * Highlights include: - GHC 7.10.3 - Major version bumps to - HUnit - OpenGL - OpenGLRaw - syb - Minor version bumps to - Cabal - case-insensitive - fgl - GLUT - GLURaw - primitive Full package and version list: https://www.haskell.org/platform/contents.html GHC release notes can be found at: http://downloads.haskell.org/~ghc/7.10.3/docs/html/users_guide/release-7-10-3.html This is the first release in which I've taken over as release manager. Thanks to Erik Rantapaa, Ben Gamari, Randy Polen and Jason Dagit for various platform related work; thanks to Oleg Grenrus and John Wiegley for additional testing; and thanks of course to Mark Lentczner for developing the new streamlined HP build process that has made things so much easier for all of us. * Windows Notes * The Haskell Platform on Windows now provides the MSys2 tools. These tools are needed when installing packages that use conf-tools (generally rare). These tools are not automatically placed onto the PATH in order avoid troubles due to MSys2 tools which have the same name as a standard Windows tool (e.g., echo, find, dir). * Future Plans * As per the November 13 email on "Haskell Platform Plans" (https://mail.haskell.org/pipermail/haskell-cafe/2015-November/122171.html) this is a modest release for ghc, and also a modest release for the platform, to put a capstone on the 7.10 series. Coming with the 8.0 platform we'll have lots of the exciting stuff that has been long promised, including a minimal distro without extra packages, a bundled stack binary, and a much-improved experience for installing build-type: configure packages (such as network) on Windows. Issues can be reported on the github tracker: https://github.com/haskell/haskell-platform/issues * Known Issues * As the platform builds were done from the tarballs lacking 7.10.3 release notes, those notes will not be present in the installed users' guides. However, they are available online, as in the link given above. Happy Haskelling, Gershom Bazerman, Haskell Platform release manager ___ Haskell mailing list Haskell@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell
Re: [Haskell-cafe] MRP, 3-year-support-window, and the non-requirement of CPP
Dear all, I think this discussion has gotten quite heated for reasons not related to the concrete MRP proposal, which, to be honest, I considered quite modest in terms of both scope and impact. Instead, I think it is a proxy for lots of remaining frustration and anxiety over the poor handling over the Foldable Traversable Proposal. I would like to remind everyone that due to the broad discussions and concerns over the proposal, a very rare, careful poll of Haskell users was taken, announced broadly in many channels. [1] The poll, overwhelmingly, revealed a mandate for the FTP. The breakdown of that mandate was 87% in favor among hobbyists and 79% in favor among non-hobbyists (who constituted a majority of those polled). I. Generalities That said, even the _best_ poll was not a substitute for a better earlier discussion. The handling of the AMP and FTP, which I think was heroic in terms of minimizing breakage while accomplishing long-desired change also still could have been better. As a whole, the work accomplished the mandate of allowing code to be written backwards-compatible without requiring CPP. However, it did not also seek to prevent warnings. This in itself was an enormous step forward from changes in the past which have _not_ even managed to prevent the need for CPP. At the time, I think it was not recognized how much desire there would be for things that were _both_ CPP free and _also_ warning-free for 3 releases. I think one of the great elements of progress in the current discussion is that there is now a proposal on the table which recognizes this, and seeks to accomplish this change in accordance with this desire. It is not the world’s most important change, but the recognition that change should seek to be both CPP _and_ warning free is a good recognition, and I’m sure it will be taken into account in future proposals as well. I don’t think it is useful to continue to have abstract discussions on the conflict between desire for incremental improvement versus the need to minimize pain on maintainers. We might as well continue to argue about the need for purely functional programming versus the need to print “hello world” to the console. Rather, we should put our collective minds together as collaborators and colleagues to accomplish _both_, and to come up with solutions that should work for everyone. To the extent this discussion has been about that, I think it has been useful and positive. However, to the extent this discussion insists, on either side, on the shallow idea that we must treat “improvement” versus “stability” as irreconcilable factions in necessary conflict, then I fear it will be a missed opportunity. II. Particulars With that in mind, I think the _concrete_ voices of concern have been the most useful. Gregory Collins’ list of issues requiring CPP should be very sobering. Of note, I think they point to areas where the core libraries committee has not paid _enough_ attention (or perhaps has not been sufficiently empowered: recall that not all core libraries fall under its maintenance [2]). Things like the newtype FFI issue, the changes to prim functions, the splitup of old-time and the changes to exception code were _not_ vetted as closely as the AMP and FTP were, or as the MRP is currently being. I don’t know all the reasons for this, but I suspect they just somewhat slipped under the radar. In any case, if all those changes were as carefully engineered as the MRP proposal has been, then imho things would have been much smoother. So, while this discussion may be frustrating, it nonetheless in some ways provides a model of how people have sought to do better and be more proactive with careful discussion of changes. This is much appreciated. Personally, since the big switch to extensible exceptions back prior in 6.10, and since the split-base nonsense prior to that, very few changes to the core libraries have really caused too much disruption in my code. Since then, the old-time cleanup was the worst, and the big sin there was that time-locale-compat was only written some time after the fact by a helpful third-party contributor and not engineered from the start. (I will note that the time library is one of the core libraries that is _not_ maintained by the core libraries committee). Outside of that, the most disruptive changes to my code that I can recall have been from changes to the aeson library over the years — particularly but not only regarding its handling of doubles. I don’t begrudge these changes — they iteratively arrived at a _much_ better library than had they not been made. [3] After than, I made a few changes regarding Happstack and Snap API changes if I recall. Additionally, the addition of “die” to System.Exit caused a few name clashes. My point is simply that there are many packages outside of base that also move, and “real” users with “real” code will these days often have quite a chain of
Re: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`
On October 5, 2015 at 10:59:35 AM, Bryan O'Sullivan (b...@serpentine.com) wrote: > I would like to suggest that the bar for breaking all existing libraries, > books, papers, > and lecture notes should be very high; and that the benefit associated with > such a breaking > change should be correspondingly huge. > 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? 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. So the reason for choosing to not do MRP simultaneous with AMP was precisely to allow a gradual migration path where, sans CPP, people could write code compatible with the last three versions of GHC, as the general criteria has been. So without arguing the necessity or not, I just want to weigh in with a technical opinion that if this goes through, my _estimation_ is that there will be a smooth and relatively painless migration period, the sky will not fall, good teaching material will remain good, those libraries that bitrot will tend to do so for a variety of reasons more significant than this, etc. It is totally reasonable to have a discussion on whether this change is worth it at all. But let’s not overestimate the cost of it just to further tip the scales :-) —gershom ___ 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`
On October 5, 2015 at 6:00:00 AM, Simon Thompson (s.j.thomp...@kent.ac.uk) wrote: > Hello all. I write this to be a little provocative, but … > > It’s really interesting to have this discussion, which pulls in all sorts of > well-made > points about orthogonality, teaching, the evolution of the language and so > on, but it > simply goes to show that the process of evolving Haskell is profoundly broken. > > Other languages do evolve, but in a managed and reflective way. Simply > throwing in changes > that would have a profound impact on systems that are commercially and > potentially safety > critical in an à la carte, offhand, way seems like a breakdown of the > collective responsibility > of the Haskell community to its users and, indirectly, to its future. Hi Simon. I do in fact think this is provocative :-P I want to object here to your characterization of what has been going on as “simply throwing in changes”. The proposal seems very well and carefully worked through to provide a good migration strategy, even planning to alter the source of GHC to ensure that adequate hints are given for the indefinite transition period. I also want to object to the idea that these changes would have “a profound impact on systems”. As it stands, and I think this is an important criteria in any change, when “phase 2” goes into affect, code that has compiled before may cease to compile until a minor change is made. However, code that continues to compile will continue to compile with the same behavior. Now as to process itself, this is a change to core libraries. It has been proposed on the libraries list, which seems appropriate, and a vigorous discussion has ensued. This seems like a pretty decent process to me thus far. Do you have a better one in mind? —Gershom P.S. as a general point, I sympathize with concerns about breakage resulting from this, but I also think that the migration strategy proposed is good, and if people are concerned about breakage I think it would be useful if they could explain where they feel the migration strategy is insufficient to allay their concerns. ___ Haskell-prime mailing list Haskell-prime@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
Re: [Haskell] ANN: CfN for new Haskell Prime language committee
On September 24, 2015 at 5:56:36 PM, Herbert Valerio Riedel (h...@gnu.org) wrote: > Dear Haskell Community, > > In short, it's time to assemble a new Haskell Prime language > committee. Please refer to the CfN at > > https://mail.haskell.org/pipermail/haskell-prime/2015-September/003936.html > > for more details. Thanks Herbert, for taking the lead in getting this process rolling again. I just wanted to take a moment to note that, while I am not in academia myself, it seems to me that serving on the committee should be a very good opportunity for graduate students and younger PhDs to engage in what is considered “service to the profession,” as much so as reviewing papers or such. While nailing down extensions to a language spec is not necessarily a glamorous task, it is certainly one that is important. Furthermore, given the growth in the use of Haskell as a general purpose programming language adopted across many application domains, involvement with the language standardization process seems like it is potentially more of a “feather in one’s professional cap” than in years prior. Cheers, Gershom ___ Haskell mailing list Haskell@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell
[Haskell] ANN: Creation of Haskell-Community list for Haskell.org Community Infrastructure Discussions
Dear all, The haskell.org committee [1] had a productive week during ICFP, and at some point we'll try to write up some of the small things underway and future plans -- many things are quite tentative at the moment. However, one thing that became clear to us (well, thanks to the useful prodding of SPJ) is that we have historically participated in discussions in other venues (-cafe, reddit, etc) and then had our own internal discussions (few, seldom, and largely organizational to be honest) on the low-traffic committee [at] haskell.org mail alias. But this leaves open people wondering what those discussions are. And it also leaves open where the *designated place* to discuss haskell.org community infrastructure is. The haskell-infrastructure [2] list is very quiet and really about technical considerations. Meanwhile, -cafe, reddit and soforth are about anything and everything. So we created another list, which will be a place where we seek to have our discussions related to plans for haskell.org committee work, and where we invite everyone to join us. This new list is the haskell-community list: https://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community The committee alias will still work, and is still the way to just write directly to the members of the committee -- no list to join. But if you wish to have a discussion about how we have things set up on haskell community infrastructure, services provided, and that we might wish to add, and how you can help (or even just what your thoughts are on how things might be done), now there is a good place for that. Hope to continue conversations with many of you there, Gershom (for the haskell.org committee) [1] https://wiki.haskell.org/Haskell.org_committee [2] http://community.galois.com/mailman/listinfo/haskell-infrastructure ___ Haskell mailing list Haskell@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell
Re: tweaking text on the ghc downloads page
Ok, this is now done. Rather than “Stop” it now says the hopefully slightly less confusing “Take Notice,” and the text is otherwise as I proposed. I agree that this is only a tiny step in a more general streamining of this whole process. Cheers, Gershom On June 26, 2015 at 11:29:25 AM, Mark Lentczner (mark.lentcz...@gmail.com) wrote: Well - it isn't objectionable but it is, at best, a stop gap. Ultimately, what people want when they want to get Haskell installed is a big button marked Download - that when pressed starts the download immediately. This is true for beginners and seasoned users alike. It is true on all web sites for all things. Every link we put in their way looses some percentage, and increases the frustration of others. This change makes it: 1) Google search GHC 2) Latest news..., search and find Download in left bar, click 3) Stop! ..., click downloads 4) You've got options ..., click Platform 5) Download button, click (That last one is actually another click and page load, but we'll be putting the download buttons on the first Platform page in this round.) The Platform team built and proposed a page for #3 (the haskell.org/downloads) page, that included the Download button for Platform on the detected users's OS, and had top bar links to other options. The sequence should be this: 1) Google search GHC 2) GHC is cool... Get it with a full Haskell distribution, click 3) (on haskell.org/downloads): Download Haskell Platform... Download button, click A page for #3 was built by the Haskell Platform team that included links to other options. You can preview it here: http://45.55.156.136:8000/demo-3200/download-plan-a2.html — Mark ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
tweaking text on the ghc downloads page
I know there is a plan for some broader ghc webpage redesign. In the meantime, apparently people find the current Stop text terribly troublesome. This is because, of course, it points to the platform and now some people believe that a minimal distribution is more usable, etc. Just to take this issue off the agenda, I would like, if there are no objections, to just change that text as follows. Current: Stop! For most users, we recommend installing the _Haskell Platform_ instead of GHC. The current Haskell Platform release includes a recent GHC release as well as some other tools (such as cabal), and a larger set of libraries that are known to work together. Proposed: Stop! For most users, we recommend installing _a proper distribution_ instead of just GHC. A distribution includes a recent GHC release as well as other important tools (such as cabal, for installing libraries), and potentially a broader set of libraries known to work together. And where before the Haskell Platform text would link to of course the platform page, the new proper distribution text would now link to https://www.haskell.org/downloads where we could then argue to our heart's content about the best way to present the various download and installation options as we go forward. So, this doesn't resolve any controversy, but it at least centralizes it. If there's no objection, I'll try to get to this tomorrow? --Gershom ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
RE: tweaking text on the ghc downloads page
Sure. Ccing him on this thread now. (Note that we’re having a seperate discussion he’s involved with on -infra about signposting the HP and other options on the haskell.org/downloads page — so this is in a sense, about just making sure we only have the one big bikeshed to color rather than many little ones :-P) —Gershom On June 26, 2015 at 11:03:33 AM, Simon Peyton Jones (simo...@microsoft.com) wrote: I’m ok with all of this, but I’d like just to check with Mark L to see how he suggests signposting the HP Simon From: Glasgow-haskell-users [mailto:glasgow-haskell-users-boun...@haskell.org] On Behalf Of Michael Snoyman Sent: 26 June 2015 15:59 To: Gershom B; Glasgow-Haskell-Users users Subject: Re: tweaking text on the ghc downloads page One point I've seen users confused about in the past is that some guides recommend downloading GHC directly as part of setting up a full distribution, e.g.: https://www.haskell.org/downloads/linux (manual install) I'd take the STOP out entirely, and just give a link to the /downloads page, to avoid this confusion. The rest of your text looks spot on to me, it's literally the one word STOP that seems to have people out of sorts most often. On Fri, Jun 26, 2015 at 5:54 PM Gershom B wrote: I know there is a plan for some broader ghc webpage redesign. In the meantime, apparently people find the current Stop text terribly troublesome. This is because, of course, it points to the platform and now some people believe that a minimal distribution is more usable, etc. Just to take this issue off the agenda, I would like, if there are no objections, to just change that text as follows. Current: Stop! For most users, we recommend installing the _Haskell Platform_ instead of GHC. The current Haskell Platform release includes a recent GHC release as well as some other tools (such as cabal), and a larger set of libraries that are known to work together. Proposed: Stop! For most users, we recommend installing _a proper distribution_ instead of just GHC. A distribution includes a recent GHC release as well as other important tools (such as cabal, for installing libraries), and potentially a broader set of libraries known to work together. And where before the Haskell Platform text would link to of course the platform page, the new proper distribution text would now link to https://www.haskell.org/downloads where we could then argue to our heart's content about the best way to present the various download and installation options as we go forward. So, this doesn't resolve any controversy, but it at least centralizes it. If there's no objection, I'll try to get to this tomorrow? --Gershom ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
[Haskell] ANN: New Haskell.org Committee Members
Following the self-nomination period and discussion, the Haskell.org committee has selected new members: * Edward Kmett (reappointment) * Ryan Trinkle * John Wiegley As per the rules of the committee, this discussion was held among the current members of the committee, and the outgoing members of the committee who were not seeking reappointment. Thank you to all candidates who submitted a self-nomination. All of the nominations we received were very strong, and we would encourage all those who nominated themselves to consider self-nominating again in the future. We would also like to thank our two outgoing members, Jason Dagit and Brent Yorgey, for their service. Cheers, Gershom ___ Haskell mailing list Haskell@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell
[Haskell] Help wanted with Wiki.Haskell.Org
One of the central repositories of knowledge in the Haskell world is the HaskellWiki (https://wiki.haskell.org). This wiki has been with the Haskell community for years, and contains a wealth of knowledge. Like other services on the haskell.org domain and with haskell.org equipment, ultimate responsibility for maintaining it falls on the Haskell Committee. However, it is a community wiki, and requires care and maintenance and contributions from all of us. The wiki has been, and continues to be, a vital component in the Haskell world. Like any wiki, it is fueled by contributions from many people, and in this sense it is thriving. However, it could use a certain amount of attention and work in three key areas. We are looking for volunteers to step up in these regards, 1) Account Creation Management: Account creation is manual only because spambots otherwise destroy us. It would be worth investigating if a full upgrade and new plugins could help this issue. In the meantime, the responsibility for creating new accounts has fallen on only one person for years. This is not a good situation. We would like to set up a mail alias for wiki admins and extend account creation rights to a range of people. If you would be willing to be one of a team of responders to account creation requests, please write and let us know. 2) Technical and design oversight: Now that we have a new haskell.org homepage, the current wiki frontpage could use a redesign. For that matter, the whole wiki could use a bit of a redesign to bring it into a more modern style. Along with that, it may be the case that additional plugins — such as for typesetting code or equations better — could be quite helpful. It would be good to have a mediawiki admin who wants to help improve the technical capacities of the site, as well as to overhaul its look. Again, if you are interested in taking charge of this, please let us know. 3) Content curation: One issue with a large collection of documents written by different people is the lack of curation. Some pages fall out of date, information is spread across multiple pages instead of collected together, and quality varies greatly. Without a central authority, no one is responsible (or empowered) to fix the situation. There is a balance between keeping things up-to-date and preserving the historic content of the wiki, and without people feeling empowered to make big changes, the tendency will always fall towards the latter. We're looking for people in the community to volunteer to help improve this status quo. The task, generally speaking, is to be responsible for curating and improving the content of the wiki, but that's clearly a vague description with lots of room for individual embellishment. This doesn't need to be a single person either: a team working in a coordinated fashion could be incredibly effective. Once more, depending on response, we’d be happy to designate and empower people to make broader changes on the wiki or to organize a team to do so. If you are interested in this as well, please let us know. Gershom, for the Haskell.org Committee ___ Haskell mailing list Haskell@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell
[Haskell] Call for Haskell.org committee self-nominations
Dear Haskellers, We have been overdue for some time in calling for a new round of nominations to the Haskell.org Committee. We have three members due for retirement -- Jason Dagit, Edward Kmett, and Brent Yorgey. The committee would like to thank them for their excellent service. To nominate yourself, please send an email to committee at haskell.org by 21 April 2015. The retiring members are eligible to re-nominate themselves. Please feel free to include any information about yourself that you think will help us to make a decision. Being a member of the committee does not necessarily require a significant amount of time, but committee members should aim to be responsive during discussions when the committee is called upon to make a decision. Strong leadership, communication, and judgement are very important characteristics for committee members. The role is about setting policy, providing direction/guidance for Haskell.org infrastructure, planning for the long term, and being fiscally responsible with the Haskell.org funds (and donations). As overseers for policy regarding the open source side of Haskell, committee members must also be able to set aside personal or business related bias and make decisions with the good of the open source Haskell community in mind. More details about the committee's roles and responsibilities are on *https://wiki.haskell.org/Haskell.org_committee https://wiki.haskell.org/Haskell.org_committee* If you have any questions about the process, please feel free to e-mail us at committee at haskell.org or to contact one of us individually. Regards, Gershom ___ Haskell mailing list Haskell@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell
[Haskell] Haskell.org Committee Financial Statement 2014
Dear Haskellers, The Haskell.org Committee [1] manages funds for haskell.org and oversees haskell.org infrastructure. The funds available to Haskell.org generally come from two sources: 1) Mentor payments from the Google Summer of Code program. 2) Since the end of 2013, occasional donations [2] from the Haskell community at large. Our funds are held by Software in the Public Interest, a 501(c)3 US non-profit, through which we also accept donations. In return for its services, SPI receives 5% of donations to Haskell.org. According to our charter, Each year, the committee will post a statement of the haskell.org assets, and the transactions for that year.” We apologize for having been delinquent in this regard. Included in this message is a brief statement of Haskell.org assets over the period 31 December 2013 - 31 December 2014, as well as an approximate breakdown of expenses. The statements we receive from the SPI are not in the most usable format [3], and we hope to provide more accurate accounting in the future. Note that this statement does not reflect 2014 GSoC income, as that had not posted as of 31 December 2014. Thus the fact that we are in the black this year is entirely due to your generous donations. Thank you all so much! 1. Income and Expenses Total income over 2014: 5,187.00 Total expenses over 2014: 2,523.22 Net income over 2014: 2,663.78 2. Expense breakdown Approximate monthly hosting fees (Hetzner): 160.00 Total approximate hosting fees: 1920.00 Other approximate expenses: 603.22 (Other expenses consist of A] payment processing fees for received funds and B] the 5% of donated funds transferred to the SPI). 3. Total Balance Balance as of 31 December 2013: 23,759.13 Balance as of 31 December 2014: 26,422.91 [1] https://wiki.haskell.org/Haskell.org_committee [2] https://wiki.haskell.org/Donate_to_Haskell.org [3] Those wishing to examine further for themselves can find the reports posted to the spi-general list: http://lists.spi-inc.org/pipermail/spi-general/ Best, Gershom Bazerman for the Haskell.org Committee ___ Haskell mailing list Haskell@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell
[Haskell] The Future of Community.Haskell.Org
This message is intended to kick off a discussion on the state of the Community.Haskell.Org server and possible future plans. Included below is the text of a blog post on the infra blog ( https://blog.haskell.org/post/the_future_of_community_haskell_org/) We would especially like input and feedback from those who use or rely on any community.haskell.org services or accounts. We don't want to leave you in the lurch, and want to make sure that you feel your needs can be taken care of smoothly, even as we look to wind things down. Feedback is welcome via email (to admin@h.o) as a post on the blog, or via the reddit discussion ( http://www.reddit.com/r/haskell/comments/2wwc42/the_future_of_communityhaskellorg_request_for/ ) - - - Community.haskell.org is a server in our ecosystem that comparatively few know about these days. It actually was, to my knowledge, a key part of how the whole haskell.org community infrastructure got set up way back when. The sparse homepage still even says: This server is run by a mysterious group of Haskell hackers who do not wish to be known as a Cabal, and is funded from money earned by haskell.org mentors in the Google Summer-of-Code programme. At a certain point after this server was created, it ceased to be run by a mysterious group of Haskell hackers and instead became managed officially by the haskell.org Committee that we know today. You can see the original announcement email in the archives https://mail.haskell.org/pipermail/haskell/2010-November/022375.html. The community server, first set up in 2007 https://mail.haskell.org/pipermail/haskell/2007-June/019592.html played a key role back before the current set of cloud-based services we know today was around. It provided a shared host which could provide many of the services a software project needs -- VCS hosting, public webspace for documentation, issue trackers, mailing lists, and soforth. Today, the server is somewhat of a relic of another time. People prefer to host projects in places like github, bitbucket, or darcs hub http://hub.darcs.net/. Issue trackers likewise tend to be associated with these hosts, and there are other free, hosted issue trackers around as well. When folks want a mailing list, they tend to reach for google groups. Meanwhile, managing a big box full of shell account has become a much more difficult, riskier proposition. Every shell account is a security vulnerability waiting to happen, and there are more adversarial scriptkiddie hackers than ever looking to claim new boxes to spam and otherwise operate from. Managing a mailman installation is likewise more difficult. There are more spammers out there, with better methods, and unmaintained lists quickly can turn into ghost towns filled with pages of linkspam and nothing but. The same sad fate falls on unmaintained tracs. As a whole, the internet is a more adversarial world for small, self-hosted services, especially those whose domain names have some google juice. We think it would be good to, to the extent possible, get out of the business of doing this sort of hosting. And indeed, very few individuals tend to request accounts, since there are now so many nicer, better ways of getting the benefits that community.haskell.org once was rare in providing. So what next? Well, we want to end of life most of community.haskell.org, but in as painless a way as possible. This means finding what few tracs, if any, are still active, and helping their owners migrate. Similarly for mailing lists. Of course we will find a way to continue to host their archives for historical purposes. Similarly, we will attempt to keep source repositories accessible for historical purposes, but would very much like to encourage owners to move to more well supported code hosting. One purpose that, until recently, was hard to serve elsewhere was in hosting of private darcs repositories with shared access -- such as academics might use to collaborate on a work in project. However, that capability is now also provided on http://hub.darcs.net. At this point, we can't think of anything in this regard that is not better provided elsewhere -- but if you can, please let us know. On webspace, it may be the case that a little more leniency is in order. For one, it is possible to provide restricted accounts that are able to control web-accessible files but have no other rights. For another, while many open source projects now host documentation through github pages or similar, and there are likewise many services for personal home pages, nonetheless it seems a nice thing to allow projects to host their resources on a system that is not under the control of a for-profit third party that, ultimately is responsible to its bottom line and not its users. But all this is open for discussion! Community.haskell.org was put together to serve the open source community of Haskell developers, and its direction needs to be determined based on feedback regarding current needs. What do
[Haskell] ANN: New Haskell.org Homepage Now Live
I’m pleased to announce that http://www.haskell.org has received its first significant design update since 2010! More significantly, for the first time since 2006 it is not a wiki, but an actual language homepage. More significantly still, for the first time ever, the Haskell homepage now runs on a fully Haskell-powered stack. I suppose some people might also be interested in the fact that it looks quite nice, and has significantly cleaned up the information it presents, so as to provide a more focused experience for newcomers looking to explore the language. The page is now includes the collective work of over 230 commits by 17 contributors. First and foremost among those is Chris Done, who conceived the vision, wrote the bulk of the code, and executed the design. Also thanks to our many admins, including Austin Seipp, Ricky Elrod, et al., who managed the deployment, and have been working behind the scenes to continue to modernize and update our creaking infrastructure. Onto a few key things to remember: * The wiki is still around at https://wiki.haskell.org and it is still a fantastic resource. It is now speedy again, and we have an account creation process. By all means, jump in, and help curate and cultivate its wealth of knowledge. * The new site is all on github: https://github.com/haskell-infra/hl — there you will also find an issue tracker as well. We are sure there are many gaffes, gaps, and oddities that remain to be patched up in the site, especially with regards to its content. Tickets, pull requests, and comments are encouraged. * The official home for our mailinglists is now http://mail.haskell.org — hopefully this will cause no problems or confusion, and the redirects should be in place properly. Please let us know if there are any issues. * We think we covered everything, but there is the possibility that some item, service, or redirect broke in the course of this transition. Please let us know if this is the case. * If you have been responsible for some subdirectory under the www.haskell.org banner, then you will find that you do not yet have an account on the new server. Please contact us and we’ll get you set up to continue to maintain that portion of the site. * As always, you can reach the haskell ops and admin team at ad...@haskell.org, or on freenode irc at #haskell-infrastructure. Regards, Gershom (and also the Haskell.org Committee and Haskell.org Admin Team) ___ Haskell mailing list Haskell@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell
Re: Discovery of source dependencies without --make
Is -M perhaps what you’ve been looking for?
https://downloads.haskell.org/~ghc/7.8.3/docs/html/users_guide/separate-compilation.html#makefile-dependencies
-g
On November 27, 2014 at 5:32:01 AM, Lars Hupel (l...@hupel.info) wrote:
The only problem I see with that is that error message locations will be
a bit off, since the file being compiled is different from the file
submitted. But since we're in the hacks territory anyway, this could be
fixed up with a simple regex :-)
... or line pragmas :-)
I'm currently investigating another route though. I wrote a simple
program which parses some Haskell files with haskell-src-exts (we
actually even need hse-cpp), builds a graph with all known
dependencies, uses topSort from Data.Graph to come up with a proper
ordering and prints the source files in that order. That approach feels
a lot safer to me. It can be used like:
ghc -c $(cabal exec topoSort ${files[@]})
(Never mind the obvious unsafe file name handling.)
The downside is that parse errors won't be reported by GHC, but by our
preprocessing tool.
(I've attached the tool, but keep in mind it's just a quick proof of
concept.)
Cheers
Lars
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
[Haskell] Call for Presentations: Compose Conference [New York, Jan 30-Feb 1]
Compose is a new conference for typed functional programmers, focused specifically on Haskell, OCaml, F#, and related technologies. It will be held in New York from Jan 30-Feb 1, and registration is opening shortly. http://www.composeconference.org/ Below is our call for presentations. We recognize the deadline is tight, so feel free to submit proposals and ideas on the less-polished side. Call for Presentations and Speakers. http://www.composeconference.org/call/index.html --- The audience for Compose is Haskell, OCaml, or F# developers who are looking to increase their skills or learn new technologies and libraries. Presentations should be aimed at teaching or introducing new ideas or tools. We are also interested in presentations aiming at taking complex concepts, such as program derivation, and putting them into productive use. However proposals on anything that you suspect our audience may find interesting are welcome. The following are some of the types of talks we would welcome: Library/Tool Talks — Exploring the uses of a powerful toolkit or library, be it for parsing, testing, data access and analysis, or anything else. Production Systems — Experience reports on deploying functional techniques in real systems; insights revealed, mistakes made, lessons learned. Theory made Practical — Just because it’s locked away in papers doesn’t mean it’s hard! Accessible lectures on classic results and why they matter to us today. Such talks can include simply introducing the principles of a field of research so as to help the audience read up on it in the future; from abstract machines to program derivation to branch-and-bound algorithms, the sky’s the limit. We also welcome proposals for more formal tutorials for the Sunday unconference. Such tutorials should be aimed at a smaller audience of beginner-to-novice understanding, and ideally include hands-on exercises. The due date for submissions is November 30, 2014. We will send out notice of acceptance by 10 December. We prefer that submissions be via the EasyChair website (https://easychair.org/conferences/?conf=compose2015). Please suggest a title, and describe the topic you intend to speak on. Additional information may be included on both your expertise and the interesting elements of your topic, going on what might be included in a public abstract. Furthermore, if your abstract doesn't feel final—don't worry! We'll work with you to polish it up. If you want to discuss your proposal(s) before submitting, or to further nail down what you intend to speak on, please feel free to contact us at i...@composeconference.org. We're happy to work with you, even if you are a new or inexperienced speaker, to help your talk be great. —Gershom ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: RFC: Dropping Windows XP support
One concern here is that even with XP falling out of support, Windows Server 2003 remains supported through July 2015, and so we should give it a little chunk of time after that falls out of support from Microsoft before we stop supporting that. I think the limitations in Server 2003 are roughly the same as XP. http://www.microsoft.com/en-us/server-cloud/products/windows-server-2003/ However, the next Windows Server (2008) should share all Vista features. Cheers, Gershom On November 7, 2014 at 1:16:39 PM, Austin Seipp (aus...@well-typed.com) wrote: Hi all, This is a quick discussion about the current system requirements for Windows builds. Spurred by a recent[1] LLVM discussion, I'd like to raise the question of dropping support for Windows XP, and bumping the minimum required version to Windows Vista or even Windows 7. For one, Microsoft doesn't support XP anymore, so most people are moving off it anyway. 'Soon' even XP Embedded will be obsoleted. But second, Vista and beyond introduced useful new APIs we could use. I was digging through the LLVM thread and two came out to me: 1) We could switch to using slim reader/writer locks, which in some workloads may work out better than critical sections (they'll win on more read-heavy workloads). The downsides is there's no recursive locking but we don't use that anyway (and recursive locks are considered bad by many anyway[2]). 2) We could probably use an actual condition variables API that was introduced with Vista. Currently we use a giant EVENT object to emulate the API, which could be replaced with the real deal. Both of these could be nice wins for simplicity and performance I think. I know there are some corporate users out there who this may impact, and users as well. I'd like to know what people think. Particularly what version we should standardize on. FWIW, I don't plan on changing any of this until the 7.12 release at least. [1] http://article.gmane.org/gmane.comp.compilers.llvm.devel/78419 [2] http://www.zaval.org/resources/library/butenhof1.html -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GADTs in implementation of Template Haskell
On October 20, 2014 at 2:35:27 PM, Richard Eisenberg (e...@cis.upenn.edu) wrote: Having done so, I'm not 100% convinced that this is the right thing to do. I would love feedback on my full, concrete proposal available at https://ghc.haskell.org/trac/ghc/wiki/Design/TemplateHaskellGADTs Is this a change for the better or worse? Feel free either to comment on the wiki page or to this email. Thanks! Richard As I understand it, the big downsides are that we don’t get `gunfold` for Dec and Pragma, and we may not get `Generic` instances for them at all. At first this felt pretty bad, but then I reviewed how generics and TH tend to get used together, and now I’m not _quite_ as anxious. In my mind the main use case for them is in things like this: http://www.well-typed.com/blog/2014/10/quasi-quoting-dsls/ — skimming the code involved, and the way `dataToExpQ` and friends tend to work, the key bit is having the generic instances on what we’re inducting on, not what we’re building… By the time we hit concrete TH syntax, it feels a bit late to be doing further generic transformations on it, so I have a suspicion this won’t hit anyone. I certainly don’t think it’ll affect _my_ uses of TH at least :-) Cheers, Gershom ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell] [Haskell-cafe] What happened to hugs?
I’m happy to announce that http://www.haskell.org/hugs has now been resuscitated, and should contain complete documentation and downloads for the Hugs system. Furthermore we’re working on putting put in place a redirect so that http://cvs.haskell.org will be able to point to the new location to keep older links intact. If there are any other stale links anyone would like patched up or binary releases that people feel should be pointed to, please let us know at ad...@haskell.org. -gershom On September 25, 2014 at 11:57:58 PM, Rustom Mody (rustompm...@gmail.com) wrote: On Thu, Sep 11, 2014 at 2:03 AM, Thorsten Rangwich wrote: Hi, I suppose this question is not new, but neither google nor a manual search file be file through the archives brought enlightement. www.haskell.org/hugs still exists, but none of the links there does work. Documentation and source point to cvs.haskell.org (server does not exist) and development points to http://hackage.haskell.org/trac/hugs (page does not exist). Was it migrated to somewhere else or is it dead - in latter case the page would not make sense any more. Sad that hugs links are now dead. There is still gofer (the predecessor to hugs). The original of Mark Jones and modifications made by me in the early 90s and the whys of these modifications are at http://blog.languager.org/2014/09/pugofer.html Raskell (iPad app) provided a development environment usinh hugs, so I would at least like to install hugs on my Mac as well... Dont know about macs but last I knew it was compiling with gcc on linux (in all of 10 seconds!) ___ Haskell-Cafe mailing list haskell-c...@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell-cafe] ANN: NY Haskell presents Edward Kmett on Lenses, Folds, and Traversals -- Wed., December 12
The first NY Haskell Users Group meetup was a great success -- with roughly sixty attendees and conversations that stretched far too late for a weekday night. Video and slides are available for both the Practical Data Processing and Cloud Haskell talks: Video: http://vimeo.com/53906049 Slides on Practical Data Processing: http://gbaz.github.com/slides/PracticalData-11-2012.pdf Slides on Cloud Haskell: http://gbaz.github.com/slides/cloud-11-2012.html Source for Cloud Haskell: https://github.com/gbaz/slides/blob/gh-pages/cloud-11-2012.lhs We expect our next meetup will be equally exciting, at a bare minimum. We're actively seeking cool talks and presentations. If you're not a New York local, but may be passing through or are in the tri-state area or thereabouts, and would like to present some code or research with even tangentially real-world implications to an informed and appreciated audience, please do get in touch :-) Also, there will be a NY tech holiday party on December 11th, which we are organizing along with other NY technology and PL groups. Details are available at the on the meetup site: http://www.meetup.com/NY-Haskell/. Finally, at some point, we will probably cease to spam -cafe with announcements of all our events, so even if you can't make it to the next few ones, registering at the meetup site is the best way to stay on top of what we will have planned. - - - - Lenses, Folds, and Traversals presented by Edward Kmett Wednesday, December 12, 2012 7:00 PM To 9:00 PM Pivotal Labs, 841 Broadway New York, NY (8th Floor) RSVP: http://www.meetup.com/NY-Haskell/ Edward Kmett will introduce his lens library, which provides a highly composable toolbox for accessing and modifying multiple parts of data structures. From simple beginnings, starting with building blocks such as fmap and (.), we will build up combinators suitable for working with a wide array of data structures. These generalize the notions you already know how to use into a form that is easier to compose, and simultaneously allow them to be used for monomorphic containers such as Data.Text. All without compromising on your ability to reason about them using laws! Once we've built up some foundations, we'll do a bit of a deep dive, exploring consequences of this design. We will discuss the efficient generic programming programming framework exported by lens, and type-safe Traversal-based zippers. Familiarity with the Applicative and Traversable classes from the Haskell base libraries will be helpful (links provided below), but a basic understanding of the concepts will be introduced we go along. Attendees should expect to be gobsmacked with a newfound appreciation for the power of a little (or a lot of) abstraction. Useful (but not mandatory) references: The lens library and documentation: http://hackage.haskell.org/package/lens A previous, more introductory talk on how to use the lenses Edward Kmett wrote for the scalaz in the Scala programming language: https://www.youtube.com/watch?v=efv0SQNde5Q The original Applicative paper: http://www.soi.city.ac.uk/~ross/papers/Applicative.pdf Lots of information on Traversable: http://www.cs.ox.ac.uk/jeremy.gibbons/publications/iterator.pdf A write-up of this talk, as presented at the Bay Area Haskell Users Group: http://google-opensource.blogspot.com/2012/10/lenses-folds-and-traversals-haskell.html ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell] ANN: New York Haskell Users Group -- First Meeting on Wed., Nov 14.
The (arguably) greatest city in the U.S. now (finally) has a users group for (unarguably) the greatest programming language anywhere. We're very happy to announce the inaugural meeting of the New York Haskell Users Group. We intend this group to be welcoming to new developers, but with enough substance to keep old Haskell hands interested and amused. If you're in the area but can't make it, you can join the meetup regardless at http://www.meetup.com/NY-Haskell/ to stay informed of future events. We plan to have a mix of talks and experience reports at all levels, so if you will be passing through town and might have something to say, let us know! Two Haskell Talks: Practical Data Processing With Haskell _and_ Putting Cloud Haskell to Work Wednesday, November 14, 2012 7:00 PM To 9:00 PM Pivotal Labs, 841 Broadway New York, NY RSVP: http://www.meetup.com/NY-Haskell/ We're kicking off the New York Haskell Users Group with two great talks, one for people just getting started and one for those with some experience already. Both should be accessible and enjoyable no matter how much (or little) you already know. Food and refreshments will be provided, courtesy of the generosity of Pivotal Labs, and after the talks, we're planning to keep the discussion going over food and drink at a nearby establishment. 7pm - Practical Data Processing With Haskell: Ozgun Ataman will give an introductory talk on Haskell, diving right in with how you can start using Haskell for practical data manipulation tasks today. You'll be introduced to a typical setup for Haskell development and given a demonstration of how a common data format (CSV, JSON, etc.) can be parsed, processed and finally output using Haskell. The talk will include a small actual Haskell program to be modified live and some commentary around using Haskell in practical applications. 8pm - Putting Cloud Haskell to Work for Distributed Computing: Gershom Bazerman will give an overview of the new distributed-process library that implements Cloud Haskell, providing computation across heterogeneous nodes through a message passing interface. He will discuss what this new tool provides out of the box, and what you'll have to bring to the table. The talk will include some code samples using the new library, as well as some experience about what it's like to use Haskell for distributed computing in the real world. Speaker Biographies: Ozgun Ataman is the founder of Soostone, a managment consulting and analytics company built on Haskell. He is the author of many open-source Haskell libraries, and is a contributor to the Snap web framework. Gershom Bazerman is a developer at SP Capital IQ. He is most well known in the Haskell community as the author of the JMacro library for programmatic generation of JavaScript, and for one well-received April fools joke. ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell-cafe] ANN: New York Haskell Users Group -- First Meeting on Wed., Nov 14.
The (arguably) greatest city in the U.S. now (finally) has a users group for (unarguably) the greatest programming language anywhere. We're very happy to announce the inaugural meeting of the New York Haskell Users Group. We intend this group to be welcoming to new developers, but with enough substance to keep old Haskell hands interested and amused. If you're in the area but can't make it, you can join the meetup regardless at http://www.meetup.com/NY-Haskell/ to stay informed of future events. We plan to have a mix of talks and experience reports at all levels, so if you will be passing through town and might have something to say, let us know! Two Haskell Talks: Practical Data Processing With Haskell _and_ Putting Cloud Haskell to Work Wednesday, November 14, 2012 7:00 PM To 9:00 PM Pivotal Labs, 841 Broadway New York, NY RSVP: http://www.meetup.com/NY-Haskell/ We're kicking off the New York Haskell Users Group with two great talks, one for people just getting started and one for those with some experience already. Both should be accessible and enjoyable no matter how much (or little) you already know. Food and refreshments will be provided, courtesy of the generosity of Pivotal Labs, and after the talks, we're planning to keep the discussion going over food and drink at a nearby establishment. 7pm - Practical Data Processing With Haskell: Ozgun Ataman will give an introductory talk on Haskell, diving right in with how you can start using Haskell for practical data manipulation tasks today. You'll be introduced to a typical setup for Haskell development and given a demonstration of how a common data format (CSV, JSON, etc.) can be parsed, processed and finally output using Haskell. The talk will include a small actual Haskell program to be modified live and some commentary around using Haskell in practical applications. 8pm - Putting Cloud Haskell to Work for Distributed Computing: Gershom Bazerman will give an overview of the new distributed-process library that implements Cloud Haskell, providing computation across heterogeneous nodes through a message passing interface. He will discuss what this new tool provides out of the box, and what you'll have to bring to the table. The talk will include some code samples using the new library, as well as some experience about what it's like to use Haskell for distributed computing in the real world. Speaker Biographies: Ozgun Ataman is the founder of Soostone, a managment consulting and analytics company built on Haskell. He is the author of many open-source Haskell libraries, and is a contributor to the Snap web framework. Gershom Bazerman is a developer at SP Capital IQ. He is most well known in the Haskell community as the author of the JMacro library for programmatic generation of JavaScript, and for one well-received April fools joke. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
A Modest Records Proposal
The records discussion has been really complicated and confusing. But
I have a suggestion that should provide a great deal of power to
records, while being mostly[1] backwards-compatible with Haskell 2010.
Consider this example:
data A a = A{a:a, aa::a, aaa :: a - A (a - a)}
data B a = B{aaa :: a - A (a - a), a :: A}
Now what is the type of this?
a a aa = a{a = a, aaa = aa}
Using standard Haskell typeclasses this is a difficult question to
answer. The types of for A and B do not unify in an obvious way.
However, while they are intensionally quite distinct, they unify
trivially extensionally. The obvious thing to do is then to extend the
type system with extensional equality on record functions.
Back when Haskell was invented, extensional equality was thought to be
hard. But purity was thought to be hard too, and so were Monads. Now,
we know that function existentionality is easy. In fact, if we add the
Univalence Axiom to GHC[2], then this is enough to get function
existensionality. This is a well-known result of Homotopy Type
Theory[3], which is a well-explored approach that has existed for at
least a few years and produced more than one paper[4]. Homotopy Type
Theory is so sound and well understood that it has even been
formalized in Coq.
Once we extend GHC with homotopies, it turns out that records reduce
to mere syntactic sugar, and there is a natural proof of their
soundness (Appendix A). Furthermore, there is a canonical projection
for any group of fields (Appendix B). Even better, we can make .
into the identity path operator, unifying its uses in composition and
projection. In fact, with extended (parenthesis-free) section rules,
. can also be used to terminate expressions, making Haskell friendly
not only to programmers coming from Java, but also to those coming
from Prolog!
After some initial feedback, I'm going to create a page for the
Homotopy Extensional Records Proposal (HERP) on trac. There are really
only a few remaining questions. 1) Having introduced homotopies, why
not go all the way and introduce dependent records? In fact, are HERP
and Dependent Extensional Records Proposal (DERP) already isomorphic?
My suspicion is that HERP is isomorphic, but DERP is not. However, I
can only get away with my proof using Scott-free semantics. 2) Which
trac should I post this too? Given how well understood homotopy type
theory is, I'm tempted to bypass GHC entirely and propose this for
haskell-prime. 3) What syntax should we use to represent homotopies?
See extend discussion in Appendix C.
HTH HAND,
Gershom
[1] To be precise, 100% of Haskell 2010 programs should, usually, be
able to be rewritten to work with this proposal with a minimal set of
changes[1a].
[1a] A minimal set of changes is defined as the smallest set of
changes necessary to make to a Haskell 2010 program such that it works
with this proposal. We can arrive at these changes by the following
procedure: 1) Pick a change[1b]. 2) Is it minimal? If so keep it. 3)
are we done? If not, make another change.
[1b] To do this constructively, we need an order. I suggest the lo
mein, since noodles give rise to a free soda.
[2] I haven't looked at the source, but I would suggest putting it in
the file Axioms.hs.
[3] http://homotopytypetheory.org/
[4] http://arxiv.org/
*Appendix A: A Natural Proof of the Soundness of HERP
Take the category of all types in HERP, with functions as morphisms.
Call it C. Take the category of all sound expressions in HERP, with
functions as morphisms. Call it D. Define a full functor from C to D.
Call it F. Define a faithful functor on C and D. Call it G. Draw the
following diagram.
F(X)F(Y)
| |
| |
| |
G(X)G(Y)
Define the arrows such that everything commutes.
*Appendix B: Construction of a Canonical Projection for Any Group of Fields.
1) Take the fields along the homotopy to an n-ball.
2) Pack them loosely with newspaper and gunpowder.
3) Project them from a cannon.
In an intuitionistic logic, the following simplification is possible:
1) Use your intuition.
*Appendix C: Homotopy Syntax
Given that we already are using the full unicode set, what syntax
should we use to distinguish paths and homotopies? At first, I thought
we could avoid providing any syntax for homotopies at all. Haskell is
a language with type inference, so we should just be able to infer
paths and homotopies behind the scenes by adding homotopies to the
type system. That's a very nice answer in theory. But in the real
world, when we're writing code that solves actual problems,
theoretical niceties break down. What if a user wants to use a
nonstandard homotopy?
Why should we stop them just because we're too lazy to come up with a
good syntax? I then realized that we keep running out of syntax
because we've limited ourselves to unicode. Instead, I propose we add
a potentially infinite universe of identifiers: youtube videos. For
example, the higher inductive type
[Haskell-cafe] A Modest Records Proposal
The records discussion has been really complicated and confusing. But
I have a suggestion that should provide a great deal of power to
records, while being mostly[1] backwards-compatible with Haskell 2010.
Consider this example:
data A a = A{a:a, aa::a, aaa :: a - A (a - a)}
data B a = B{aaa :: a - A (a - a), a :: A}
Now what is the type of this?
a a aa = a{a = a, aaa = aa}
Using standard Haskell typeclasses this is a difficult question to
answer. The types of for A and B do not unify in an obvious way.
However, while they are intensionally quite distinct, they unify
trivially extensionally. The obvious thing to do is then to extend the
type system with extensional equality on record functions.
Back when Haskell was invented, extensional equality was thought to be
hard. But purity was thought to be hard too, and so were Monads. Now,
we know that function existentionality is easy. In fact, if we add the
Univalence Axiom to GHC[2], then this is enough to get function
existensionality. This is a well-known result of Homotopy Type
Theory[3], which is a well-explored approach that has existed for at
least a few years and produced more than one paper[4]. Homotopy Type
Theory is so sound and well understood that it has even been
formalized in Coq.
Once we extend GHC with homotopies, it turns out that records reduce
to mere syntactic sugar, and there is a natural proof of their
soundness (Appendix A). Furthermore, there is a canonical projection
for any group of fields (Appendix B). Even better, we can make .
into the identity path operator, unifying its uses in composition and
projection. In fact, with extended (parenthesis-free) section rules,
. can also be used to terminate expressions, making Haskell friendly
not only to programmers coming from Java, but also to those coming
from Prolog!
After some initial feedback, I'm going to create a page for the
Homotopy Extensional Records Proposal (HERP) on trac. There are really
only a few remaining questions. 1) Having introduced homotopies, why
not go all the way and introduce dependent records? In fact, are HERP
and Dependent Extensional Records Proposal (DERP) already isomorphic?
My suspicion is that HERP is isomorphic, but DERP is not. However, I
can only get away with my proof using Scott-free semantics. 2) Which
trac should I post this too? Given how well understood homotopy type
theory is, I'm tempted to bypass GHC entirely and propose this for
haskell-prime. 3) What syntax should we use to represent homotopies?
See extend discussion in Appendix C.
HTH HAND,
Gershom
[1] To be precise, 100% of Haskell 2010 programs should, usually, be
able to be rewritten to work with this proposal with a minimal set of
changes[1a].
[1a] A minimal set of changes is defined as the smallest set of
changes necessary to make to a Haskell 2010 program such that it works
with this proposal. We can arrive at these changes by the following
procedure: 1) Pick a change[1b]. 2) Is it minimal? If so keep it. 3)
are we done? If not, make another change.
[1b] To do this constructively, we need an order. I suggest the lo
mein, since noodles give rise to a free soda.
[2] I haven't looked at the source, but I would suggest putting it in
the file Axioms.hs.
[3] http://homotopytypetheory.org/
[4] http://arxiv.org/
*Appendix A: A Natural Proof of the Soundness of HERP
Take the category of all types in HERP, with functions as morphisms.
Call it C. Take the category of all sound expressions in HERP, with
functions as morphisms. Call it D. Define a full functor from C to D.
Call it F. Define a faithful functor on C and D. Call it G. Draw the
following diagram.
F(X)F(Y)
| |
| |
| |
G(X)G(Y)
Define the arrows such that everything commutes.
*Appendix B: Construction of a Canonical Projection for Any Group of Fields.
1) Take the fields along the homotopy to an n-ball.
2) Pack them loosely with newspaper and gunpowder.
3) Project them from a cannon.
In an intuitionistic logic, the following simplification is possible:
1) Use your intuition.
*Appendix C: Homotopy Syntax
Given that we already are using the full unicode set, what syntax
should we use to distinguish paths and homotopies? At first, I thought
we could avoid providing any syntax for homotopies at all. Haskell is
a language with type inference, so we should just be able to infer
paths and homotopies behind the scenes by adding homotopies to the
type system. That's a very nice answer in theory. But in the real
world, when we're writing code that solves actual problems,
theoretical niceties break down. What if a user wants to use a
nonstandard homotopy?
Why should we stop them just because we're too lazy to come up with a
good syntax? I then realized that we keep running out of syntax
because we've limited ourselves to unicode. Instead, I propose we add
a potentially infinite universe of identifiers: youtube videos. For
example, the higher inductive type
Re: thoughts on the record update problem
On Thu, Mar 8, 2012 at 4:52 PM, Greg Weber g...@gregweber.info wrote: syntax we would like. Does that make sense? I take it that you agree that we should separate the discussion of semantics from implementation: this is a perfect example of why. If we can describe semantics without concern for the possibility/needs of implementation, then I've got some _great_ proposals I'd like to make! --Gershom ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
[Haskell] ANN: JMacro 0.3.2, A library/dsl for generating Javascript
JMacro on hackage: http://hackage.haskell.org/package/jmacro This is the first official release announcement for JMacro, which has been on hackage in some form for over a year, and in the current version since July. JMacro is a library for the programmatic generation of Javascript code. It is designed to be multipurpose -- it is useful whether you are writing nearly vanilla Javascript or you are programmatically generating Javascript either in an ad-hoc fashion or as the backend to a compiler or EDSL. It provides support for hygienic names, as well as sharing of names between the generated Javascript and embedded Haskell antiquotation. In this release it also includes a module which allows the generation of RPC request/response pairs, allowing a lightweight implementation of AJAX-heavy applications. JMacro provides a simple, lightweight quasiquoted syntax that is mainly compatible with standard Javascript. Most Javascript code in the wild can be used as JMacro code with no or minimal modification. However, JMacro extends Javascript syntax in a number of Haskell-friendly ways, including whitespace function application and single character lambdas. Syntax is statically checked at compile time. JMacro expressions may contain antiquoted Haskell code. This code may generate further JMacro code, or it may generate any of a range of standard Haskell types, which are able to be marshalled into JMacro through typeclass methods. JMacro also provides an executable, which allows the standalone processing of JMacro code into Javascript. For more information, see both Hackage and the JMacro documentation on the HaskellWiki: http://www.haskell.org/haskellwiki/Jmacro Some examples or idiomatic JMacro code are available in the source of its provided Javascript Prelude: http://hackage.haskell.org/packages/archive/jmacro/0.3.2/doc/html/src/Language-Javascript-JMacro-Prelude.html#jmPrelude Future work on JMacro, when time is available, is geared towards providing an optional layer of static typing with type inference. Patches, bug reports, and feature requests are all very welcome. ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell-cafe] ANN: JMacro 0.3.2, A library/dsl for generating Javascript
JMacro on hackage: http://hackage.haskell.org/package/jmacro This is the first official release announcement for JMacro, which has been on hackage in some form for over a year, and in the current version since July. JMacro is a library for the programmatic generation of Javascript code. It is designed to be multipurpose -- it is useful whether you are writing nearly vanilla Javascript or you are programmatically generating Javascript either in an ad-hoc fashion or as the backend to a compiler or EDSL. It provides support for hygienic names, as well as sharing of names between the generated Javascript and embedded Haskell antiquotation. In this release it also includes a module which allows the generation of RPC request/response pairs, allowing a lightweight implementation of AJAX-heavy applications. JMacro provides a simple, lightweight quasiquoted syntax that is mainly compatible with standard Javascript. Most Javascript code in the wild can be used as JMacro code with no or minimal modification. However, JMacro extends Javascript syntax in a number of Haskell-friendly ways, including whitespace function application and single character lambdas. Syntax is statically checked at compile time. JMacro expressions may contain antiquoted Haskell code. This code may generate further JMacro code, or it may generate any of a range of standard Haskell types, which are able to be marshalled into JMacro through typeclass methods. JMacro also provides an executable, which allows the standalone processing of JMacro code into Javascript. For more information, see both Hackage and the JMacro documentation on the HaskellWiki: http://www.haskell.org/haskellwiki/Jmacro Some examples or idiomatic JMacro code are available in the source of its provided Javascript Prelude: http://hackage.haskell.org/packages/archive/jmacro/0.3.2/doc/html/src/Language-Javascript-JMacro-Prelude.html#jmPrelude Future work on JMacro, when time is available, is geared towards providing an optional layer of static typing with type inference. Patches, bug reports, and feature requests are all very welcome. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
