From dyaitskov at gmail.com Fri Apr 1 15:56:08 2022 From: dyaitskov at gmail.com (Daneel Yaitskov) Date: Fri, 1 Apr 2022 11:56:08 -0400 Subject: [Haskell-cafe] Model beverage Message-ID: Hi List, I came to Haskell from Java. At the beginning I was trying to map traditional notions of mainstream languages onto the FP world as “How to replace inheritance and late binding?”, etc. If Java developers drink coffee, then what is the model beverage for haskellers? “Psyllium Husk” fits the role, because besides phonetic similarities, the beverage is lazy (the recipe is simple - mix powder with water) and immutable (goes through the intestinal tract largely unaltered). Plus it is far off mainstream. -- Best regards, Daniil Iaitskov -------------- next part -------------- An HTML attachment was scrubbed... URL: From olf at aatal-apotheke.de Sat Apr 2 15:55:44 2022 From: olf at aatal-apotheke.de (Olaf Klinke) Date: Sat, 02 Apr 2022 17:55:44 +0200 Subject: [Haskell-cafe] Model beverage Message-ID: <212013c2661ea0610670ae355ece732b8036072e.camel@aatal-apotheke.de> > Hi List, > > I came to Haskell from Java. At the beginning I was trying to map > traditional notions of mainstream languages onto the FP world as “How to > replace inheritance and late binding?”, etc. > > If Java developers drink coffee, then what is the model beverage for > haskellers? > > “Psyllium Husk” fits the role, because besides phonetic similarities, the > beverage is lazy (the recipe is simple - mix powder with water) and > immutable (goes through the intestinal tract largely unaltered). Plus it is > far off mainstream. > > > -- > > Best regards, > Daniil Iaitskov Absinthe comes to mind. It is very potent, popular among philosophersbut drives you crazy if consumed regularly, in large quantities. Cheers, Olaf From tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk Sat Apr 2 18:50:26 2022 From: tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk (Tom Ellis) Date: Sat, 2 Apr 2022 19:50:26 +0100 Subject: [Haskell-cafe] =?utf-8?q?RFC=3A_removing_=E2=80=9Calternative_ins?= =?utf-8?q?tallation_methods=E2=80=9D_from_haskell=2Eorg_=28or_finding_the?= =?utf-8?q?m_owners=29?= Message-ID: The Haskell.org committee is considering removing the "alternative installation options" section from the [downloads page of haskell.org](https://www.haskell.org/downloads/) and we seek the opinion of the community. If you would like to share your opinion we prefer that you do so [on the haskell.org issue tracker](https://github.com/haskell-infra/www.haskell.org/issues/170), but failing that, in this email thread is fine too. ### Background The [downloads page of haskell.org](https://www.haskell.org/downloads/) suggests using ghcup and stack to obtain a toolchain. These two tools are widely used in the community, actively maintained and kept up-to-date. The page also provides a number of "alternative installation options" (see below, or on the page itself, for the list). The Haskell.org committee does not have the resources to ensure that these alternative installation options are kept maintained and confirmed working. We don't even know if anyone uses them. Anyone who uses them is likely to be an "advanced user" anyway, since they require more expertise to implement. stack and ghcup presumably work well on all those platforms, are the most well-maintained installation options and most suitable for beginners. ### Possibilities We have a couple of options: 1. Remove all the alternative installation options. 2. Keep (some of) the alternative installation options and find community volunteers to maintain them. The volunteers will be responsible for ensuring verifying on a regular basis that their instructions are still working, submitting timely corrections when necessary, and responding promptly on the issue tracker to questions about their installation instructions. ### What we would like from you * Please share your opinion about removing the alternative installation options, especially if you are a user of one of them! * If you are willing to maintain an alternative installation option, please speak up! ### Current alternative installation options * Linux Ubuntu (confusing (see https://github.com/haskell-infra/www.haskell.org/issues/16) and probably outdated) * Linux Debian (links to https://downloads.haskell.org/~debian/ which doesn't support Debian 11 Bullseye) * Linux Fedora * Linux EPEL for RHEL/CentOS/etc * Linux Arch * Linux openSUSE Leap * Linux openSUSE Tumbleweed * Linux Gentoo * Windows Chocolatey From arrowd at freebsd.org Sat Apr 2 20:19:01 2022 From: arrowd at freebsd.org (Gleb Popov) Date: Sat, 2 Apr 2022 23:19:01 +0300 Subject: [Haskell-cafe] =?utf-8?q?RFC=3A_removing_=E2=80=9Calternative_ins?= =?utf-8?q?tallation_methods=E2=80=9D_from_haskell=2Eorg_=28or_find?= =?utf-8?q?ing_them_owners=29?= In-Reply-To: References: Message-ID: On Sat, Apr 2, 2022 at 9:51 PM Tom Ellis < tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk> wrote: > The Haskell.org committee is considering removing the "alternative > installation options" section from the [downloads page of > haskell.org](https://www.haskell.org/downloads/) and we seek the > opinion of the community. If you would like to share your opinion we > prefer that you do so [on the haskell.org issue > tracker](https://github.com/haskell-infra/www.haskell.org/issues/170), > but failing that, in this email thread is fine too. > > ### Background > > The [downloads page of > haskell.org](https://www.haskell.org/downloads/) suggests using ghcup > and stack to obtain a toolchain. These two tools are widely used in > the community, actively maintained and kept up-to-date. The page also > provides a number of "alternative installation options" (see below, or > on the page itself, for the list). > Huh, why does this page say > To install stack, follow the instructions here (N.B. stack does not support FreeBSD) ? Stack works on FreeBSD just fine for a long time. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk Sat Apr 2 20:25:31 2022 From: tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk (Tom Ellis) Date: Sat, 2 Apr 2022 21:25:31 +0100 Subject: [Haskell-cafe] =?utf-8?q?RFC=3A_removing_=E2=80=9Calternative_ins?= =?utf-8?q?tallation_methods=E2=80=9D_from_haskell=2Eorg_=28or_finding_the?= =?utf-8?q?m_owners=29?= In-Reply-To: References: Message-ID: On Sat, Apr 02, 2022 at 11:19:01PM +0300, Gleb Popov wrote: > On Sat, Apr 2, 2022 at 9:51 PM Tom Ellis < > tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk> wrote: > > > The Haskell.org committee is considering removing the "alternative > > installation options" section from the [downloads page of > > haskell.org](https://www.haskell.org/downloads/) and we seek the > > opinion of the community. If you would like to share your opinion we > > prefer that you do so [on the haskell.org issue > > tracker](https://github.com/haskell-infra/www.haskell.org/issues/170), > > but failing that, in this email thread is fine too. > > > > ### Background > > > > The [downloads page of > > haskell.org](https://www.haskell.org/downloads/) suggests using ghcup > > and stack to obtain a toolchain. These two tools are widely used in > > the community, actively maintained and kept up-to-date. The page also > > provides a number of "alternative installation options" (see below, or > > on the page itself, for the list). > > > > Huh, why does this page say > > > To install stack, follow the instructions here (N.B. stack does not > support FreeBSD) > > ? > > Stack works on FreeBSD just fine for a long time. I took the decision to make that claim following the (lack of) discussion at https://github.com/commercialhaskell/stack/issues/5674 If the claim is wrong perhaps you could add some commentary to that ticket. N.B. as reported by Julian Ospald the 'curl | sh' in the Stack Install/ugrade guide[1] doesn't work on FreeBSD. How are FreeBSD users supposed to install it? Tom [1] https://docs.haskellstack.org/en/stable/install_and_upgrade/ From ivanperezdominguez at gmail.com Sat Apr 2 22:23:59 2022 From: ivanperezdominguez at gmail.com (Ivan Perez) Date: Sat, 2 Apr 2022 18:23:59 -0400 Subject: [Haskell-cafe] =?utf-8?q?RFC=3A_removing_=E2=80=9Calternative_ins?= =?utf-8?q?tallation_methods=E2=80=9D_from_haskell=2Eorg_=28or_find?= =?utf-8?q?ing_them_owners=29?= In-Reply-To: References: Message-ID: I think it's perfect as they are and I'd advise against changing it. I personally discourage the use of stack or ghcup, and would certainly prefer to see more installation methods based on package-management tools that each OS provides. I think there's something to be said in favor of using standard package-management tools that install the compiler in global space. In particular, the PPA-based installation method for Debian/Ubuntu/Mint that HVR used to maintain was excellent. It's still my preferred method (even though it's not maintained). I don't know where you are getting info about which project is used more or less, and I fear there may be a strong bias. Leaving them there is more fair, makes more people aware of their existence, and makes it more likely that newcomers will be able to participate in other efforts. For Haskell to remain a community project, it's good that we keep mentioning less popular projects, even when attention temporarily sways one way or another. If you remove other projects from the web page, you create an effect of compound interest (or compound attention) towards those projects, where they get the most contributions because they are the ones that most people are aware of because they are on the front page because they get the most contributions, and so on and so forth. Ivan On Sat, 2 Apr 2022 at 14:51, Tom Ellis < tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk> wrote: > The Haskell.org committee is considering removing the "alternative > installation options" section from the [downloads page of > haskell.org](https://www.haskell.org/downloads/) and we seek the > opinion of the community. If you would like to share your opinion we > prefer that you do so [on the haskell.org issue > tracker](https://github.com/haskell-infra/www.haskell.org/issues/170), > but failing that, in this email thread is fine too. > > ### Background > > The [downloads page of > haskell.org](https://www.haskell.org/downloads/) suggests using ghcup > and stack to obtain a toolchain. These two tools are widely used in > the community, actively maintained and kept up-to-date. The page also > provides a number of "alternative installation options" (see below, or > on the page itself, for the list). > > The Haskell.org committee does not have the resources to ensure that > these alternative installation options are kept maintained and > confirmed working. We don't even know if anyone uses them. Anyone who > uses them is likely to be an "advanced user" anyway, since they > require more expertise to implement. stack and ghcup presumably work > well on all those platforms, are the most well-maintained installation > options and most suitable for beginners. > > ### Possibilities > > We have a couple of options: > > 1. Remove all the alternative installation options. > 2. Keep (some of) the alternative installation options and find > community volunteers to maintain them. The volunteers will be > responsible for ensuring verifying on a regular basis that their > instructions are still working, submitting timely corrections when > necessary, and responding promptly on the issue tracker to questions > about their installation instructions. > > ### What we would like from you > > * Please share your opinion about removing the alternative > installation options, especially if you are a user of one of them! > * If you are willing to maintain an alternative installation option, > please speak up! > > > ### Current alternative installation options > > * Linux Ubuntu (confusing (see > https://github.com/haskell-infra/www.haskell.org/issues/16) and > probably outdated) > * Linux Debian (links to https://downloads.haskell.org/~debian/ > which doesn't support Debian 11 Bullseye) > * Linux Fedora > * Linux EPEL for RHEL/CentOS/etc > * Linux Arch > * Linux openSUSE Leap > * Linux openSUSE Tumbleweed > * Linux Gentoo > * Windows Chocolatey > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From a.pelenitsyn at gmail.com Sun Apr 3 02:58:04 2022 From: a.pelenitsyn at gmail.com (Artem Pelenitsyn) Date: Sat, 2 Apr 2022 22:58:04 -0400 Subject: [Haskell-cafe] =?utf-8?q?RFC=3A_removing_=E2=80=9Calternative_ins?= =?utf-8?q?tallation_methods=E2=80=9D_from_haskell=2Eorg_=28or_find?= =?utf-8?q?ing_them_owners=29?= In-Reply-To: References: Message-ID: > * I don't know where you are getting info about which project is used more or less* Well, that's why we have the State of Haskell survey, right?.. > Which installation methods do you use for your Haskell compiler? Here are results for options gathered >10%. [image: Screenshot from 2022-04-02 22-39-01.png] Since I'm already writing this, I add my 2c. I've been using HVR's PPA for years, switched to ghcup and never regretted it. It's strictly better in terms of 1) UI/UX, 2) maintenance (shout out to ghcup's maintenance team: it's just amazing). I believe haskell.org should refer to the most modern, nice-looking, wide-used (see results above), well-maintained solutions that deliver reasonably fresh versions of the toolchain. This contradicts with trying to survey most known solutions (because e.g. some of those will not be maintained or will have outdated versions, etc.). Alternative methods section requires crowdsourcing, and the best way to handle that imo is a wiki page. I think the current section for "alternative methods" should be turned into one and referenced from the Downloads page with the asterisk "for the curious". If only we had a healthy functioning wiki, sigh… -- Kind regards, Artem On Sat, 2 Apr 2022 at 18:26, Ivan Perez wrote: > I think it's perfect as they are and I'd advise against changing it. > > I personally discourage the use of stack or ghcup, and would certainly > prefer to see more installation methods based on package-management tools > that each OS provides. I think there's something to be said in favor of > using standard package-management tools that install the compiler in global > space. > > In particular, the PPA-based installation method for Debian/Ubuntu/Mint > that HVR used to maintain was excellent. It's still my preferred method > (even though it's not maintained). I don't know where you are getting info > about which project is used more or less, and I fear there may be a strong > bias. > > Leaving them there is more fair, makes more people aware of their > existence, and makes it more likely that newcomers will be able to > participate in other efforts. > > For Haskell to remain a community project, it's good that we keep > mentioning less popular projects, even when attention temporarily sways one > way or another. If you remove other projects from the web page, you create > an effect of compound interest (or compound attention) towards those > projects, where they get the most contributions because they are the ones > that most people are aware of because they are on the front page because > they get the most contributions, and so on and so forth. > > Ivan > > On Sat, 2 Apr 2022 at 14:51, Tom Ellis < > tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk> wrote: > >> The Haskell.org committee is considering removing the "alternative >> installation options" section from the [downloads page of >> haskell.org](https://www.haskell.org/downloads/) and we seek the >> opinion of the community. If you would like to share your opinion we >> prefer that you do so [on the haskell.org issue >> tracker](https://github.com/haskell-infra/www.haskell.org/issues/170), >> but failing that, in this email thread is fine too. >> >> ### Background >> >> The [downloads page of >> haskell.org](https://www.haskell.org/downloads/) suggests using ghcup >> and stack to obtain a toolchain. These two tools are widely used in >> the community, actively maintained and kept up-to-date. The page also >> provides a number of "alternative installation options" (see below, or >> on the page itself, for the list). >> >> The Haskell.org committee does not have the resources to ensure that >> these alternative installation options are kept maintained and >> confirmed working. We don't even know if anyone uses them. Anyone who >> uses them is likely to be an "advanced user" anyway, since they >> require more expertise to implement. stack and ghcup presumably work >> well on all those platforms, are the most well-maintained installation >> options and most suitable for beginners. >> >> ### Possibilities >> >> We have a couple of options: >> >> 1. Remove all the alternative installation options. >> 2. Keep (some of) the alternative installation options and find >> community volunteers to maintain them. The volunteers will be >> responsible for ensuring verifying on a regular basis that their >> instructions are still working, submitting timely corrections when >> necessary, and responding promptly on the issue tracker to questions >> about their installation instructions. >> >> ### What we would like from you >> >> * Please share your opinion about removing the alternative >> installation options, especially if you are a user of one of them! >> * If you are willing to maintain an alternative installation option, >> please speak up! >> >> >> ### Current alternative installation options >> >> * Linux Ubuntu (confusing (see >> https://github.com/haskell-infra/www.haskell.org/issues/16) and >> probably outdated) >> * Linux Debian (links to https://downloads.haskell.org/~debian/ >> which doesn't support Debian 11 Bullseye) >> * Linux Fedora >> * Linux EPEL for RHEL/CentOS/etc >> * Linux Arch >> * Linux openSUSE Leap >> * Linux openSUSE Tumbleweed >> * Linux Gentoo >> * Windows Chocolatey >> >> _______________________________________________ >> Haskell-Cafe mailing list >> To (un)subscribe, modify options or view archives go to: >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> Only members subscribed via the mailman list are allowed to post. > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screenshot from 2022-04-02 22-39-01.png Type: image/png Size: 14887 bytes Desc: not available URL: From tanuki at gmail.com Sun Apr 3 03:46:56 2022 From: tanuki at gmail.com (Akhra Gannon) Date: Sat, 2 Apr 2022 20:46:56 -0700 Subject: [Haskell-cafe] Model beverage In-Reply-To: <212013c2661ea0610670ae355ece732b8036072e.camel@aatal-apotheke.de> References: <212013c2661ea0610670ae355ece732b8036072e.camel@aatal-apotheke.de> Message-ID: Well if that's the path we're going down, consider: Mushroom tea. It will take you outside of time, make you contemplate infinity, and take your thoughts in abstract directions few other experiences can prepare you for; but in the end you come away surprisingly refreshed! On Sat, Apr 2, 2022, 9:00 AM Olaf Klinke wrote: > Absinthe comes to mind. It is very potent, popular among philosophersbut > drives you crazy if consumed regularly, in large quantities. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk Sun Apr 3 12:35:44 2022 From: tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk (Tom Ellis) Date: Sun, 3 Apr 2022 13:35:44 +0100 Subject: [Haskell-cafe] =?utf-8?q?RFC=3A_removing_=E2=80=9Calternative_ins?= =?utf-8?q?tallation_methods=E2=80=9D_from_haskell=2Eorg_=28or_finding_the?= =?utf-8?q?m_owners=29?= In-Reply-To: References: Message-ID: On Sat, Apr 02, 2022 at 06:23:59PM -0400, Ivan Perez wrote: > In particular, the PPA-based installation method for Debian/Ubuntu/Mint > that HVR used to maintain was excellent. It's still my preferred method > (even though it's not maintained). I don't know where you are getting info > about which project is used more or less, and I fear there may be a strong > bias. Thanks Ivan. As a user of the Ubunto PPA would you be willing to become an "owner" of the documentation of that method on the Downloads page? As an owner you would be responsible for ensuring the information on the page stays up-to-date, making timely corrections when necessary, and handling user issues about the information. The first issue to handle is the following: https://github.com/haskell-infra/www.haskell.org/issues/16 Tom From brucker at spamfence.net Sun Apr 3 15:42:39 2022 From: brucker at spamfence.net (Achim D. Brucker) Date: Sun, 3 Apr 2022 16:42:39 +0100 Subject: [Haskell-cafe] Fully Funded PhD Positions in the Safety and Security of Advanced Systems Group (Exeter, UK, Deadline 2022-04-29) Message-ID: We have two fully funded PhD scholarships for UK applicants in the Security and Trust of Advanced Systems Group [1] (Prof. Achim Brucker [2] and Dr. Diego Marmsoler [3]) at the Department of Computer Science of the University of Exeter, UK [4]. We are looking for enthusiastic and outstanding Computer Science or Mathematics students with a strong background in at least one of the following topics: * safety or security of (software) systems, * formal modelling or formal reasoning/verification, * program analysis or program verification, * language-based security, * semantics of programming languages, * theorem proving, model checking, * cryptographic protocols, * distributed systems (e.g., blockchain), * software security, * cyber-physical systems, * specification-based testing, and * design and implementation of security architectures. The positions offer the flexibility to define the PhD topic jointly between the successful candidate and the supervisors. Interested candidates should contact the potential supervisor Prof. Achim Brucker (a.brucker at exeter.ac.uk) or Dr. Diego Marmsoler (d.marmsoler at exeter.ac.uk) to discuss their application. For more details, please consult the official advertisements: * Compositional Verification of Smart Contracts in Isabelle: https://www.exeter.ac.uk/study/funding/award/?id=4326 * Formal Verification for Safety- or Security-Critical Systems: https://www.exeter.ac.uk/study/funding/award/?id=4328 The closing date for applications is midnight on the 29th April 2022. Best, Achim and Diego [1] http://emps.exeter.ac.uk/computer-science/research/cyber-security/ [2] https://www.brucker.ch/ [3] https://marmsoler.com/ [4] http://emps.exeter.ac.uk/computer-science/ -- Prof. Achim Brucker | Chair in Cybersecurity & Head of Group | University of Exeter https://www.brucker.ch | https://logicalhacking.com/blog @adbrucker | @logicalhacking From ivanperezdominguez at gmail.com Sun Apr 3 17:26:55 2022 From: ivanperezdominguez at gmail.com (Ivan Perez) Date: Sun, 3 Apr 2022 13:26:55 -0400 Subject: [Haskell-cafe] =?utf-8?q?RFC=3A_removing_=E2=80=9Calternative_ins?= =?utf-8?q?tallation_methods=E2=80=9D_from_haskell=2Eorg_=28or_find?= =?utf-8?q?ing_them_owners=29?= In-Reply-To: References: Message-ID: On Sat, 2 Apr 2022 at 22:58, Artem Pelenitsyn wrote: > > * I don't know where you are getting info about which project is used > more or less* > Well, that's why we have the State of Haskell survey, right?.. > I've been programming in Haskell for more than 20 years (more than half of those professionally to some extent). In all that time, I think I filled in one, and just one, of those, when I was first aware of their existence (years ago). Even basing a decision on that survey carries with it a strong bias: you'd be basing that decision on the kind of respondent who would participate in the first place. Who are you leaving behind? Ivan -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk Sun Apr 3 17:34:38 2022 From: tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk (Tom Ellis) Date: Sun, 3 Apr 2022 18:34:38 +0100 Subject: [Haskell-cafe] =?utf-8?q?RFC=3A_removing_=E2=80=9Calternative_ins?= =?utf-8?q?tallation_methods=E2=80=9D_from_haskell=2Eorg_=28or_finding_the?= =?utf-8?q?m_owners=29?= In-Reply-To: References: Message-ID: On Sun, Apr 03, 2022 at 01:26:55PM -0400, Ivan Perez wrote: > On Sat, 2 Apr 2022 at 22:58, Artem Pelenitsyn > wrote: > > > * I don't know where you are getting info about which project is used > > more or less* > > Well, that's why we have the State of Haskell survey, right?.. > > I've been programming in Haskell for more than 20 years (more than half of > those professionally to some extent). > > In all that time, I think I filled in one, and just one, of those, when I > was first aware of their existence (years ago). > > Even basing a decision on that survey carries with it a strong bias: you'd > be basing that decision on the kind of respondent who would participate in > the first place. > > Who are you leaving behind? Well, good question, but back at you: who are you discouraging from Haskell by keeping a large number of complex, unmaintained, possibly completely wrong, installation instruction on the Downloads page? Tom From spam at scientician.net Sun Apr 3 17:57:47 2022 From: spam at scientician.net (Bardur Arantsson) Date: Sun, 3 Apr 2022 19:57:47 +0200 Subject: [Haskell-cafe] =?utf-8?q?RFC=3A_removing_=E2=80=9Calternative_ins?= =?utf-8?q?tallation_methods=E2=80=9D_from_haskell=2Eorg_=28or_finding_the?= =?utf-8?q?m_owners=29?= In-Reply-To: References: Message-ID: On 03/04/2022 19.34, Tom Ellis wrote: > Well, good question, but back at you: who are you discouraging from > Haskell by keeping a large number of complex, unmaintained, possibly > completely wrong, installation instruction on the Downloads page? > I have no strong feelings either way, but would it perhaps be viable to just leave that "Alternative installation options" as a simple link to a separate page perhaps be sufficent to guide people to use either of the two 'main' options while still leaving the alternatives semi-documented? Has that been considered? (I think just adding a disclaimer that the 'alternative methods' are not supported per se, but perhaps simultaneously encouraging corrections might be a way to lessen the maintenance burden?) Regards, From tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk Sun Apr 3 18:10:05 2022 From: tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk (Tom Ellis) Date: Sun, 3 Apr 2022 19:10:05 +0100 Subject: [Haskell-cafe] =?utf-8?q?RFC=3A_removing_=E2=80=9Calternative_ins?= =?utf-8?q?tallation_methods=E2=80=9D_from_haskell=2Eorg_=28or_finding_the?= =?utf-8?q?m_owners=29?= In-Reply-To: References: Message-ID: On Sun, Apr 03, 2022 at 07:57:47PM +0200, Bardur Arantsson wrote: > On 03/04/2022 19.34, Tom Ellis wrote: > > Well, good question, but back at you: who are you discouraging from > > Haskell by keeping a large number of complex, unmaintained, possibly > > completely wrong, installation instruction on the Downloads page? > > I have no strong feelings either way, but would it perhaps be viable to > just leave that "Alternative installation options" as a simple link to a > separate page perhaps be sufficent to guide people to use either of the > two 'main' options while still leaving the alternatives semi-documented? > Has that been considered? > > (I think just adding a disclaimer that the 'alternative methods' are not > supported per se, but perhaps simultaneously encouraging corrections > might be a way to lessen the maintenance burden?) The problem that I am trying to solve is that no one with maintenance responsibility for the haskell.org website knows if those alternative installation methods work, are up-to-date, are currently supported by the (external) teams that put them together, etc.. It is not doing right by the community to publish information that we cannot support or verify. If someone is willing to be the "owner" of a particular installation method, to ensure it is kept up to date and high quality, then we'll keep it! To reiterate what I said in my first email, we can ... "Keep (some of) the alternative installation options and find community volunteers to maintain them. The volunteers will be responsible for ensuring verifying on a regular basis that their instructions are still working, submitting timely corrections when necessary, and responding promptly on the issue tracker to questions about their installation instructions" Tom From spam at scientician.net Sun Apr 3 18:23:58 2022 From: spam at scientician.net (Bardur Arantsson) Date: Sun, 3 Apr 2022 20:23:58 +0200 Subject: [Haskell-cafe] =?utf-8?q?RFC=3A_removing_=E2=80=9Calternative_ins?= =?utf-8?q?tallation_methods=E2=80=9D_from_haskell=2Eorg_=28or_finding_the?= =?utf-8?q?m_owners=29?= In-Reply-To: References: Message-ID: On 03/04/2022 20.10, Tom Ellis wrote: > On Sun, Apr 03, 2022 at 07:57:47PM +0200, Bardur Arantsson wrote: >> On 03/04/2022 19.34, Tom Ellis wrote: >>> Well, good question, but back at you: who are you discouraging from >>> Haskell by keeping a large number of complex, unmaintained, possibly >>> completely wrong, installation instruction on the Downloads page? >> >> I have no strong feelings either way, but would it perhaps be viable to >> just leave that "Alternative installation options" as a simple link to a >> separate page perhaps be sufficent to guide people to use either of the >> two 'main' options while still leaving the alternatives semi-documented? >> Has that been considered? >> >> (I think just adding a disclaimer that the 'alternative methods' are not >> supported per se, but perhaps simultaneously encouraging corrections >> might be a way to lessen the maintenance burden?) > > The problem that I am trying to solve is that no one with maintenance > responsibility for the haskell.org website knows if those alternative > installation methods work, are up-to-date, are currently supported by > the (external) teams that put them together, etc.. It is not doing > right by the community to publish information that we cannot support > or verify. > > If someone is willing to be the "owner" of a particular installation > method, to ensure it is kept up to date and high quality, then we'll > keep it! To reiterate what I said in my first email, we can ... > > "Keep (some of) the alternative installation options and find > community volunteers to maintain them. The volunteers will be > responsible for ensuring verifying on a regular basis that their > instructions are still working, submitting timely corrections when > necessary, and responding promptly on the issue tracker to questions > about their installation instructions" > I did read the OP. My point was simply that it might be acceptable to have half-working (or whatever) instructions if they were squirreled away behind a link + disclaimer. That might be better for people who (for whatever reason) don't want either of the officially supported methods. Regards, From ivanperezdominguez at gmail.com Sun Apr 3 18:32:38 2022 From: ivanperezdominguez at gmail.com (Ivan Perez) Date: Sun, 3 Apr 2022 14:32:38 -0400 Subject: [Haskell-cafe] =?utf-8?q?RFC=3A_removing_=E2=80=9Calternative_ins?= =?utf-8?q?tallation_methods=E2=80=9D_from_haskell=2Eorg_=28or_find?= =?utf-8?q?ing_them_owners=29?= In-Reply-To: References: Message-ID: There's no need to keep them on a separate page. If the purpose of keeping them around (on the same or on a separate page) is to make people aware that these methods exist, putting them away on a separate page achieves none of the goals (near to no awareness) and has the same drawbacks in terms of effort required. It's sufficient to keep them on the same page in a separate section. If you are clean and organized, nobody will be confused or distracted. Ivan On Sun, 3 Apr 2022 at 14:29, Bardur Arantsson wrote: > On 03/04/2022 20.10, Tom Ellis wrote: > > On Sun, Apr 03, 2022 at 07:57:47PM +0200, Bardur Arantsson wrote: > >> On 03/04/2022 19.34, Tom Ellis wrote: > >>> Well, good question, but back at you: who are you discouraging from > >>> Haskell by keeping a large number of complex, unmaintained, possibly > >>> completely wrong, installation instruction on the Downloads page? > >> > >> I have no strong feelings either way, but would it perhaps be viable to > >> just leave that "Alternative installation options" as a simple link to a > >> separate page perhaps be sufficent to guide people to use either of the > >> two 'main' options while still leaving the alternatives semi-documented? > >> Has that been considered? > >> > >> (I think just adding a disclaimer that the 'alternative methods' are not > >> supported per se, but perhaps simultaneously encouraging corrections > >> might be a way to lessen the maintenance burden?) > > > > The problem that I am trying to solve is that no one with maintenance > > responsibility for the haskell.org website knows if those alternative > > installation methods work, are up-to-date, are currently supported by > > the (external) teams that put them together, etc.. It is not doing > > right by the community to publish information that we cannot support > > or verify. > > > > If someone is willing to be the "owner" of a particular installation > > method, to ensure it is kept up to date and high quality, then we'll > > keep it! To reiterate what I said in my first email, we can ... > > > > "Keep (some of) the alternative installation options and find > > community volunteers to maintain them. The volunteers will be > > responsible for ensuring verifying on a regular basis that their > > instructions are still working, submitting timely corrections when > > necessary, and responding promptly on the issue tracker to questions > > about their installation instructions" > > > > I did read the OP. My point was simply that it might be acceptable to > have half-working (or whatever) instructions if they were squirreled > away behind a link + disclaimer. That might be better for people who > (for whatever reason) don't want either of the officially supported > methods. > > Regards, > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk Sun Apr 3 18:35:25 2022 From: tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk (Tom Ellis) Date: Sun, 3 Apr 2022 19:35:25 +0100 Subject: [Haskell-cafe] =?utf-8?q?RFC=3A_removing_=E2=80=9Calternative_ins?= =?utf-8?q?tallation_methods=E2=80=9D_from_haskell=2Eorg_=28or_finding_the?= =?utf-8?q?m_owners=29?= In-Reply-To: References: Message-ID: On Sun, Apr 03, 2022 at 08:23:58PM +0200, Bardur Arantsson wrote: > I did read the OP. My point was simply that it might be acceptable to > have half-working (or whatever) instructions if they were squirreled > away behind a link + disclaimer. That might be better for people who > (for whatever reason) don't want either of the officially supported methods. My personal point of view is that it is counterproductive to have unverified, unmaintained information on the website anywhere, even squirreled away. But thank you for this suggestion. We will take it into consideration and enact it if there is sufficient support. Tom From allbery.b at gmail.com Sun Apr 3 18:39:47 2022 From: allbery.b at gmail.com (Brandon Allbery) Date: Sun, 3 Apr 2022 14:39:47 -0400 Subject: [Haskell-cafe] =?utf-8?q?RFC=3A_removing_=E2=80=9Calternative_ins?= =?utf-8?q?tallation_methods=E2=80=9D_from_haskell=2Eorg_=28or_find?= =?utf-8?q?ing_them_owners=29?= In-Reply-To: References: Message-ID: I have to imagine various distributions' maintainers would be unhappy to find their packaging referred to as "unverified". (Aside from Arch's, who apparently just don't care how much of a painful mess they make for their users.) On Sun, Apr 3, 2022 at 2:36 PM Tom Ellis wrote: > > On Sun, Apr 03, 2022 at 08:23:58PM +0200, Bardur Arantsson wrote: > > I did read the OP. My point was simply that it might be acceptable to > > have half-working (or whatever) instructions if they were squirreled > > away behind a link + disclaimer. That might be better for people who > > (for whatever reason) don't want either of the officially supported methods. > > My personal point of view is that it is counterproductive to have > unverified, unmaintained information on the website anywhere, even > squirreled away. But thank you for this suggestion. We will take it > into consideration and enact it if there is sufficient support. > > Tom > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -- brandon s allbery kf8nh allbery.b at gmail.com From tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk Sun Apr 3 18:47:08 2022 From: tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk (Tom Ellis) Date: Sun, 3 Apr 2022 19:47:08 +0100 Subject: [Haskell-cafe] =?utf-8?q?RFC=3A_removing_=E2=80=9Calternative_ins?= =?utf-8?q?tallation_methods=E2=80=9D_from_haskell=2Eorg_=28or_finding_the?= =?utf-8?q?m_owners=29?= In-Reply-To: References: Message-ID: Well, I'm sorry if I have made them unhappy. When I said "unverified" I was talking about the information, not the packaging. Perhaps I should have been more careful in my choice of words. Yet, their work has not been (recently) confirmed working by those responsible for maintaining www.haskell.org, nor do we have the resources to perform such confirmations. If someone is willing to put in the long term work needed to keep the information continually up to date then we will welcome continued inclusion of that information on the website. Tom On Sun, Apr 03, 2022 at 02:39:47PM -0400, Brandon Allbery wrote: > I have to imagine various distributions' maintainers would be unhappy > to find their packaging referred to as "unverified". (Aside from > Arch's, who apparently just don't care how much of a painful mess they > make for their users.) > > On Sun, Apr 3, 2022 at 2:36 PM Tom Ellis > wrote: > > > > On Sun, Apr 03, 2022 at 08:23:58PM +0200, Bardur Arantsson wrote: > > > I did read the OP. My point was simply that it might be acceptable to > > > have half-working (or whatever) instructions if they were squirreled > > > away behind a link + disclaimer. That might be better for people who > > > (for whatever reason) don't want either of the officially supported methods. > > > > My personal point of view is that it is counterproductive to have > > unverified, unmaintained information on the website anywhere, even > > squirreled away. But thank you for this suggestion. We will take it > > into consideration and enact it if there is sufficient support. From ivanperezdominguez at gmail.com Sun Apr 3 18:48:02 2022 From: ivanperezdominguez at gmail.com (Ivan Perez) Date: Sun, 3 Apr 2022 14:48:02 -0400 Subject: [Haskell-cafe] =?utf-8?q?RFC=3A_removing_=E2=80=9Calternative_ins?= =?utf-8?q?tallation_methods=E2=80=9D_from_haskell=2Eorg_=28or_find?= =?utf-8?q?ing_them_owners=29?= In-Reply-To: References: Message-ID: On Sun, 3 Apr 2022 at 14:11, Tom Ellis < tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk> wrote: > On Sun, Apr 03, 2022 at 07:57:47PM +0200, Bardur Arantsson wrote: > > On 03/04/2022 19.34, Tom Ellis wrote: It is not doing > right by the community to publish information that we cannot support > or verify. > A key factor with respect to the problem I am seeing at large, over large periods of time, is that the Haskell community has a very, very strong tendency to start new efforts instead of contributing to existing ones. We have witnessed it in the appearance of installation tools, language extensions, competing libraries, efforts to control/guide the discourse regarding key parts of the Haskell infrastructure, you name it. There were excellent, excellent methods to install and setup haskell quickly that did not warrant the creation of yet more methods. And yet, those have been created, standard installation methods abandoned, and here we are. The feeling I have is that we are going around in circles. That has left a lot of people burned out. What was once a joy (programming in Haskell) has become, for many, a drain, and they have abandoned their work when a competing effort was hyped up. I'm sure you can all identify Haskellers who have left and/or taken very long breaks due to burn out. The attitude we should have with respect to these efforts is not "can we focus on advertising what is maintained", but rather "what is the story we would like to tell, about the language, and the community". I would like the community to avoid giving a few people control over the conversation. I would like technical merit to trump over hype. And there's a lot of technical merit in solutions outside ghcup/stack that deserve attention and recognition. And the fact that not all of us agree indicates that, as a community, we should recognize those efforts and not erase them. To achieve that effect, it's enough to keep them at the bottom of the page, and anyone who determines that the effort is maintained should be welcome to move it to the top. Ivan -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivanperezdominguez at gmail.com Sun Apr 3 18:58:03 2022 From: ivanperezdominguez at gmail.com (Ivan Perez) Date: Sun, 3 Apr 2022 14:58:03 -0400 Subject: [Haskell-cafe] =?utf-8?q?RFC=3A_removing_=E2=80=9Calternative_ins?= =?utf-8?q?tallation_methods=E2=80=9D_from_haskell=2Eorg_=28or_find?= =?utf-8?q?ing_them_owners=29?= In-Reply-To: References: Message-ID: On Sun, 3 Apr 2022 at 14:48, Tom Ellis < tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk> wrote: > Yet, their work has not been (recently) confirmed working by those > responsible for maintaining www.haskell.org, nor do we have the > resources to perform such confirmations. You (I don't mean necessarily you personally) are still making a decision based on your lack of resources to determine if something is up to date. Is not that they are not up to date, it's that you don't know if they are (and you know that you don't know, since you are acknowledging it). But you are still willing to not list them. Since people are putting a lot of effort into maintaining that work, by ignoring that (due to lack of resources) you are contributing to that compound effect I was describing. They are doing this for the community, but the community seems to ignore them. I think it's more fair to acknowledge those efforts, to let people list what they think is useful for them. If the problem is understanding if those methods still work, perhaps what we need is a mechanism to keep track of installation methods available and the last time they were verified. That detailed info can be used to keep the page up to date. Ivan -------------- next part -------------- An HTML attachment was scrubbed... URL: From vamchale at gmail.com Sun Apr 3 19:05:44 2022 From: vamchale at gmail.com (Vanessa McHale) Date: Sun, 3 Apr 2022 14:05:44 -0500 Subject: [Haskell-cafe] [ANN] Jacinda 1.0.0.0 - a functional text processing language complementing sed, awk, etc. Message-ID: Hi all, I have released the 1.0.0.0 version of Jacinda, an expression-oriented text processing language for the command-line. You can find it here (Linux, mainly): https://github.com/vmchale/jacinda/releases/tag/1.0.0.0 Cheers, Vanessa McHale From olf at aatal-apotheke.de Sun Apr 3 19:14:09 2022 From: olf at aatal-apotheke.de (Olaf Klinke) Date: Sun, 3 Apr 2022 21:14:09 +0200 (CEST) Subject: [Haskell-cafe] Model beverage Message-ID: >Well if that's the path we're going down, consider: > >Mushroom tea. > >It will take you outside of time, make you contemplate infinity, and take >your thoughts in abstract directions few other experiences can prepare >you >for; but in the end you come away surprisingly refreshed! > I'd rather reserve that one for dependently-typed languages. ;-) But it shows once more how biased we Europeans are towards alcoholic drugs. Olaf >On Sat, Apr 2, 2022, 9:00 AM Olaf Klinke wrote: > >> Absinthe comes to mind. It is very potent, popular among >> philosophers but >> drives you crazy if consumed regularly, in large quantities. From dominik.schrempf at gmail.com Sun Apr 3 19:38:20 2022 From: dominik.schrempf at gmail.com (Dominik Schrempf) Date: Sun, 03 Apr 2022 21:38:20 +0200 Subject: [Haskell-cafe] =?utf-8?q?RFC=3A_removing_=E2=80=9Calternative_ins?= =?utf-8?q?tallation_methods=E2=80=9D__from_haskell=2Eorg_=28or_finding_th?= =?utf-8?q?em_owners=29?= In-Reply-To: References: Message-ID: <87pmly0x07.fsf@gmail.com> Hi, to add my two cents: I have never used GHCup, I used the Arch package repository, as well as Haskell Stack (installed using an Arch package manager) in the past, and I am using Nix with cabal-install now. I think it is good practice to encourage people to use the package managers of their respective operating systems. Repositories and powerful package managers are one of the greatest advantages of Linux based operating systems, in my opinion. I also think that Stack should be capitalized. To install stack… => To install Stack… (or probably: To install Haskell Stack…). I would also encourage people to install Stack using their package managers, and not using some shell script. I know, we trust the Stack maintainers, but somehow, I trust people developing my operating system even more than that (I guess, I have to, anyways :-)). Best, Dominik Tom Ellis writes: > The Haskell.org committee is considering removing the “alternative > installation options” section from the [downloads page of > haskell.org]() and we seek the > opinion of the community. If you would like to share your opinion we > prefer that you do so [on the haskell.org issue > tracker](), > but failing that, in this email thread is fine too. > > ### Background > > The [downloads page of > haskell.org]() suggests using ghcup > and stack to obtain a toolchain. These two tools are widely used in > the community, actively maintained and kept up-to-date. The page also > provides a number of “alternative installation options” (see below, or > on the page itself, for the list). > > The Haskell.org committee does not have the resources to ensure that > these alternative installation options are kept maintained and > confirmed working. We don’t even know if anyone uses them. Anyone who > uses them is likely to be an “advanced user” anyway, since they > require more expertise to implement. stack and ghcup presumably work > well on all those platforms, are the most well-maintained installation > options and most suitable for beginners. > > ### Possibilities > > We have a couple of options: > > 1. Remove all the alternative installation options. > 2. Keep (some of) the alternative installation options and find > community volunteers to maintain them. The volunteers will be > responsible for ensuring verifying on a regular basis that their > instructions are still working, submitting timely corrections when > necessary, and responding promptly on the issue tracker to questions > about their installation instructions. > > ### What we would like from you > > * Please share your opinion about removing the alternative > installation options, especially if you are a user of one of them! > * If you are willing to maintain an alternative installation option, > please speak up! > > > ### Current alternative installation options > > * Linux Ubuntu (confusing (see > ) and > probably outdated) > * Linux Debian (links to > which doesn’t support Debian 11 Bullseye) > * Linux Fedora > * Linux EPEL for RHEL/CentOS/etc > * Linux Arch > * Linux openSUSE Leap > * Linux openSUSE Tumbleweed > * Linux Gentoo > * Windows Chocolatey > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > > Only members subscribed via the mailman list are allowed to post. From tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk Sun Apr 3 21:24:54 2022 From: tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk (Tom Ellis) Date: Sun, 3 Apr 2022 22:24:54 +0100 Subject: [Haskell-cafe] =?utf-8?q?RFC=3A_removing_=E2=80=9Calternative_ins?= =?utf-8?q?tallation_methods=E2=80=9D_from_haskell=2Eorg_=28or_finding_the?= =?utf-8?q?m_owners=29?= In-Reply-To: References: Message-ID: On Sun, Apr 03, 2022 at 02:58:03PM -0400, Ivan Perez wrote: > On Sun, 3 Apr 2022 at 14:48, Tom Ellis wrote: > > Yet, their work has not been (recently) confirmed working by those > > responsible for maintaining www.haskell.org, nor do we have the > > resources to perform such confirmations. > > You (I don't mean necessarily you personally) are still making a decision So far no decision has been taken. The Haskell.org committee has a made a proposal and is seeking community feedback. Action will be taken based on consideration of the feedback received. > based on your lack of resources to determine if something is up to date. Is > not that they are not up to date, it's that you don't know if they are (and > you know that you don't know, since you are acknowledging it). But you are > still willing to not list them. You are correct that the proposal is to err on the side of removing information that may be unhelpful, rather than keeping information that may be helpful. I prefer the former since it seems to strike a good balance between providing a clear onboarding path to inexperienced users, providing a uniform onboarding path to make providing support easier, providing sufficient experieced users with a wide range of options, and allowing maintenance by a small group of volunteers with not much time on their hands. That said, the current downloads page says "EPEL 5 and 6 have ghc-7.0.4 and cabal-install-0.10.2" and I know for a fact that is about five years out of date. Indeed it seems that EPEL 5 was EOLed in 2017 https://fedoramagazine.org/the-end-of-the-line-for-epel-5/ > Since people are putting a lot of effort into maintaining that work, by > ignoring that (due to lack of resources) you are contributing to that > compound effect I was describing. They are doing this for the community, > but the community seems to ignore them. > > I think it's more fair to acknowledge those efforts, to let people list > what they think is useful for them. I'm very much in favour of letting people list what they think is useful for them, and to promote the OS packaging work that people have put a lot of effort in to. We simply need to find volunteers who are willing to put in the effort to keep the information we provide correct, up to date, and thus, useful. Part of this proposal is to reach out to potential volunteers. Would you be willing to volunteer? If so then please introduce yourself at the following GitHub discussion: https://github.com/haskell-infra/www.haskell.org/discussions/169 > If the problem is understanding if those methods still work, perhaps what > we need is a mechanism to keep track of installation methods available and > the last time they were verified. That detailed info can be used to keep > the page up to date. That sounds like a great idea. Would you be willing to implement that idea? Tom From tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk Sun Apr 3 21:28:31 2022 From: tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk (Tom Ellis) Date: Sun, 3 Apr 2022 22:28:31 +0100 Subject: [Haskell-cafe] =?utf-8?q?RFC=3A_removing_=E2=80=9Calternative_ins?= =?utf-8?q?tallation_methods=E2=80=9D___from_haskell=2Eorg_=28or_finding_t?= =?utf-8?q?hem_owners=29?= In-Reply-To: <87pmly0x07.fsf@gmail.com> References: <87pmly0x07.fsf@gmail.com> Message-ID: On Sun, Apr 03, 2022 at 09:38:20PM +0200, Dominik Schrempf wrote: > I also think that Stack should be capitalized. > > To install stack… => To install Stack… (or probably: To install Haskell > Stack…). We are willing to follow the advice of the s/Stack team on this matter, but even its own documentation is ambiguous on the capitalization: https://docs.haskellstack.org/en/stable/install_and_upgrade/ From allbery.b at gmail.com Sun Apr 3 21:31:22 2022 From: allbery.b at gmail.com (Brandon Allbery) Date: Sun, 3 Apr 2022 17:31:22 -0400 Subject: [Haskell-cafe] =?utf-8?q?RFC=3A_removing_=E2=80=9Calternative_ins?= =?utf-8?q?tallation_methods=E2=80=9D_from_haskell=2Eorg_=28or_find?= =?utf-8?q?ing_them_owners=29?= In-Reply-To: References: <87pmly0x07.fsf@gmail.com> Message-ID: On Sun, Apr 3, 2022 at 5:29 PM Tom Ellis wrote: > On Sun, Apr 03, 2022 at 09:38:20PM +0200, Dominik Schrempf wrote: > > I also think that Stack should be capitalized. > > We are willing to follow the advice of the s/Stack team on this > matter, but even its own documentation is ambiguous on the > capitalization: I'm inclined to agree about the capitalization just because "stack" (lowercase) already has a meaning and it could be confusing. -- brandon s allbery kf8nh allbery.b at gmail.com From migmit at gmail.com Sun Apr 3 21:33:17 2022 From: migmit at gmail.com (MigMit) Date: Sun, 3 Apr 2022 23:33:17 +0200 Subject: [Haskell-cafe] =?utf-8?q?RFC=3A_removing_=E2=80=9Calternative_ins?= =?utf-8?q?tallation_methods=E2=80=9D_from_haskell=2Eorg_=28or_finding_the?= =?utf-8?q?m_owners=29?= In-Reply-To: References: Message-ID: I think I remember myself as an inexperienced user. I might've walked away from Haskell, if I was given an instruction like "to install thing X, first install thing A, then use it to install think K, and then use that to install thing X". The longer the way between becoming curious about something and actually producing an executable, the less new users you have. > On 3 Apr 2022, at 23:24, Tom Ellis wrote: > > On Sun, Apr 03, 2022 at 02:58:03PM -0400, Ivan Perez wrote: >> On Sun, 3 Apr 2022 at 14:48, Tom Ellis wrote: >>> Yet, their work has not been (recently) confirmed working by those >>> responsible for maintaining www.haskell.org, nor do we have the >>> resources to perform such confirmations. >> >> You (I don't mean necessarily you personally) are still making a decision > > So far no decision has been taken. The Haskell.org committee has a > made a proposal and is seeking community feedback. Action will be > taken based on consideration of the feedback received. > >> based on your lack of resources to determine if something is up to date. Is >> not that they are not up to date, it's that you don't know if they are (and >> you know that you don't know, since you are acknowledging it). But you are >> still willing to not list them. > > You are correct that the proposal is to err on the side of removing > information that may be unhelpful, rather than keeping information > that may be helpful. I prefer the former since it seems to strike a > good balance between providing a clear onboarding path to > inexperienced users, providing a uniform onboarding path to make > providing support easier, providing sufficient experieced users with a > wide range of options, and allowing maintenance by a small group of > volunteers with not much time on their hands. > > That said, the current downloads page says > > "EPEL 5 and 6 have ghc-7.0.4 and cabal-install-0.10.2" > > and I know for a fact that is about five years out of date. Indeed it > seems that EPEL 5 was EOLed in 2017 > > https://fedoramagazine.org/the-end-of-the-line-for-epel-5/ > >> Since people are putting a lot of effort into maintaining that work, by >> ignoring that (due to lack of resources) you are contributing to that >> compound effect I was describing. They are doing this for the community, >> but the community seems to ignore them. >> >> I think it's more fair to acknowledge those efforts, to let people list >> what they think is useful for them. > > I'm very much in favour of letting people list what they think is > useful for them, and to promote the OS packaging work that people have > put a lot of effort in to. We simply need to find volunteers who are > willing to put in the effort to keep the information we provide > correct, up to date, and thus, useful. Part of this proposal is to > reach out to potential volunteers. Would you be willing to volunteer? > If so then please introduce yourself at the following GitHub > discussion: > > https://github.com/haskell-infra/www.haskell.org/discussions/169 > >> If the problem is understanding if those methods still work, perhaps what >> we need is a mechanism to keep track of installation methods available and >> the last time they were verified. That detailed info can be used to keep >> the page up to date. > > That sounds like a great idea. Would you be willing to implement that > idea? > > Tom > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. From tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk Sun Apr 3 21:33:47 2022 From: tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk (Tom Ellis) Date: Sun, 3 Apr 2022 22:33:47 +0100 Subject: [Haskell-cafe] Stack capitalization In-Reply-To: References: <87pmly0x07.fsf@gmail.com> Message-ID: On Sun, Apr 03, 2022 at 05:31:22PM -0400, Brandon Allbery wrote: > On Sun, Apr 3, 2022 at 5:29 PM Tom Ellis > wrote: > > On Sun, Apr 03, 2022 at 09:38:20PM +0200, Dominik Schrempf wrote: > > > I also think that Stack should be capitalized. > > > > We are willing to follow the advice of the s/Stack team on this > > matter, but even its own documentation is ambiguous on the > > capitalization: > > I'm inclined to agree about the capitalization just because "stack" > (lowercase) already has a meaning and it could be confusing. That rationale makes sense to me. Practicality dictates that this issue is more likely to be resolved if someone opens an issue about it (or better yet, submits a PR). https://github.com/haskell-infra/www.haskell.org/issues/new Tom From ruben.astud at gmail.com Mon Apr 4 02:45:35 2022 From: ruben.astud at gmail.com (Ruben Astudillo) Date: Sun, 3 Apr 2022 22:45:35 -0400 Subject: [Haskell-cafe] Default http2 library to use for client side? Message-ID: <3907ba98-8407-7b27-4ecc-a147b87584c9@gmail.com> Hello Cafe I have been looking at hackage on what is the status for http2 **client** libraries. I haven't be able to grasp what is the default or recommended solution on this space. So far I have gotten the following impressions: 1. The usual candidates such as req / wreq libraries don't seem to support it. This is caused by they being based on `http-client`. 2. There is an http2-client [1] library that fits the bill. It uses Kazu's http2 [2] underneath, but it is upper bounded to major version 2 of that library. Kazu's library is now at major version 3 and it cannot be made to use the updated version easily. 3. Kazu's http2 library on major version 3 has a module called Network.HTTP2.Client which is even more low-level than what the previous option provided but it seems recently developed. It has a code sample. 4. Haskellers are not that interested on client side http2. I am no expert on this protocol, but it seems that there is some compatibility on it where you can make an http1.1 call and the server will handle it transparently (don't quote me on this). But Haskellers certainly were (are?) excited for http2 server support on warp which landed around 2015-2016. I have concluded that using `http2` [2] with the client module as my best bet. Is this analysis correct? or should I be looking a other packages that I haven't considered? Thanks for you time reading this email. [1]: [2]: -- Rubén. (pgp: 1E88 3AC4 89EB FA22) From a.pelenitsyn at gmail.com Mon Apr 4 02:58:23 2022 From: a.pelenitsyn at gmail.com (Artem Pelenitsyn) Date: Sun, 3 Apr 2022 22:58:23 -0400 Subject: [Haskell-cafe] =?utf-8?q?RFC=3A_removing_=E2=80=9Calternative_ins?= =?utf-8?q?tallation_methods=E2=80=9D_from_haskell=2Eorg_=28or_find?= =?utf-8?q?ing_them_owners=29?= In-Reply-To: References: Message-ID: As was mentioned on a GitHub thread related to this topi, Rust has a great example of how to do it, I encourage everyone to take a look: https://www.rust-lang.org/tools/install i.e. Alternative methods are mentioned at the bottom as a link to some sort of broader language manual. The main website shouldn't be a wiki page for "known methods", it should be a safest trampoline into the language for newcomers. In the same line, saying that moving away this list from this website deprives current users of these methods is nonsense: if you use a method and it works for you — great! Nothing will change for you when (if) the Downloads page changes. A method that you are most used to has nothing to do with how we must present a gate to the language to newcomers, who are the primer clients of this page. -- Cheers, Artem On Sun, 3 Apr 2022 at 17:35, MigMit wrote: > I think I remember myself as an inexperienced user. I might've walked away > from Haskell, if I was given an instruction like "to install thing X, first > install thing A, then use it to install think K, and then use that to > install thing X". The longer the way between becoming curious about > something and actually producing an executable, the less new users you have. > > > On 3 Apr 2022, at 23:24, Tom Ellis < > tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk> wrote: > > > > On Sun, Apr 03, 2022 at 02:58:03PM -0400, Ivan Perez wrote: > >> On Sun, 3 Apr 2022 at 14:48, Tom Ellis < > tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk> wrote: > >>> Yet, their work has not been (recently) confirmed working by those > >>> responsible for maintaining www.haskell.org, nor do we have the > >>> resources to perform such confirmations. > >> > >> You (I don't mean necessarily you personally) are still making a > decision > > > > So far no decision has been taken. The Haskell.org committee has a > > made a proposal and is seeking community feedback. Action will be > > taken based on consideration of the feedback received. > > > >> based on your lack of resources to determine if something is up to > date. Is > >> not that they are not up to date, it's that you don't know if they are > (and > >> you know that you don't know, since you are acknowledging it). But you > are > >> still willing to not list them. > > > > You are correct that the proposal is to err on the side of removing > > information that may be unhelpful, rather than keeping information > > that may be helpful. I prefer the former since it seems to strike a > > good balance between providing a clear onboarding path to > > inexperienced users, providing a uniform onboarding path to make > > providing support easier, providing sufficient experieced users with a > > wide range of options, and allowing maintenance by a small group of > > volunteers with not much time on their hands. > > > > That said, the current downloads page says > > > > "EPEL 5 and 6 have ghc-7.0.4 and cabal-install-0.10.2" > > > > and I know for a fact that is about five years out of date. Indeed it > > seems that EPEL 5 was EOLed in 2017 > > > > https://fedoramagazine.org/the-end-of-the-line-for-epel-5/ > > > >> Since people are putting a lot of effort into maintaining that work, by > >> ignoring that (due to lack of resources) you are contributing to that > >> compound effect I was describing. They are doing this for the community, > >> but the community seems to ignore them. > >> > >> I think it's more fair to acknowledge those efforts, to let people list > >> what they think is useful for them. > > > > I'm very much in favour of letting people list what they think is > > useful for them, and to promote the OS packaging work that people have > > put a lot of effort in to. We simply need to find volunteers who are > > willing to put in the effort to keep the information we provide > > correct, up to date, and thus, useful. Part of this proposal is to > > reach out to potential volunteers. Would you be willing to volunteer? > > If so then please introduce yourself at the following GitHub > > discussion: > > > > https://github.com/haskell-infra/www.haskell.org/discussions/169 > > > >> If the problem is understanding if those methods still work, perhaps > what > >> we need is a mechanism to keep track of installation methods available > and > >> the last time they were verified. That detailed info can be used to keep > >> the page up to date. > > > > That sounds like a great idea. Would you be willing to implement that > > idea? > > > > Tom > > _______________________________________________ > > Haskell-Cafe mailing list > > To (un)subscribe, modify options or view archives go to: > > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > Only members subscribed via the mailman list are allowed to post. > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dominik.schrempf at gmail.com Mon Apr 4 08:06:19 2022 From: dominik.schrempf at gmail.com (Dominik Schrempf) Date: Mon, 04 Apr 2022 10:06:19 +0200 Subject: [Haskell-cafe] Stack capitalization In-Reply-To: References: <87pmly0x07.fsf@gmail.com> Message-ID: <87o81h8e6y.fsf@gmail.com> PR suggesting capitalized Stack: . Best, Dominik Tom Ellis writes: > On Sun, Apr 03, 2022 at 05:31:22PM -0400, Brandon Allbery wrote: >> On Sun, Apr 3, 2022 at 5:29 PM Tom Ellis >> wrote: >> > On Sun, Apr 03, 2022 at 09:38:20PM +0200, Dominik Schrempf wrote: >> > > I also think that Stack should be capitalized. >> > >> > We are willing to follow the advice of the s/Stack team on this >> > matter, but even its own documentation is ambiguous on the >> > capitalization: >> >> I’m inclined to agree about the capitalization just because “stack” >> (lowercase) already has a meaning and it could be confusing. > > That rationale makes sense to me. Practicality dictates that this > issue is more likely to be resolved if someone opens an issue about it > (or better yet, submits a PR). > > > > Tom > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > > Only members subscribed via the mailman list are allowed to post. From hjgtuyl at chello.nl Mon Apr 4 12:39:45 2022 From: hjgtuyl at chello.nl (Henk-Jan van Tuyl) Date: Mon, 04 Apr 2022 14:39:45 +0200 Subject: [Haskell-cafe] Model beverage In-Reply-To: References: Message-ID: The great scientist Steve Ballmer of Microsoft made us aware of the positive effects of alcohol on software development, see the science site XKCD for an explanation: The Ballmer Peak https://xkcd.com/323/ The Ballmer Peak is proven to exist according to The Observer: Bottoms Up: The Ballmer Peak Is Real, Study Says https://observer.com/2012/04/bottoms-up-the-ballmer-peak-is-real-study-says/ There is actually a number of Haskell-related drinks: Haskell wine (from South-Africa) https://images.wine.co.za/GetWineImage.ashx?ImageSize=large&IMAGEID=257316 Haskell's Rum https://cdn11.bigcommerce.com/s-taixn69rog/images/stencil/1280x1280/products/28629/806493/140542__04662.1637565821.jpg?c=1 Haskell's Vodka https://products2.imgix.drizly.com/ci-haskells-charcoal-filtered-vodka-6feea9620f64ac2d.jpeg?auto=format%2Ccompress&fm=jpg&q=20 And a recipe for the cocktail The Ross on Haskell: https://www.dmagazine.com/food-drink/2021/09/friday-cocktail-recipe-the-ross-on-haskell/#:~:text=The%20Ross%20on%20Haskell Maybe you could eat Haskell seafood to go with the drinks: https://www.haskellsseafood.com/recipes/ Worth reading is also: Getting recursively drunk with monoids https://dev.to/sshine/getting-recursively-drunk-with-monoids-2jek Regards, Henk-Jan van Tuyl On Fri, 01 Apr 2022 17:56:08 +0200, Daneel Yaitskov wrote: > Hi List, > > I came to Haskell from Java. At the beginning I was trying to map > traditional notions of mainstream languages onto the FP world as “How to > replace inheritance and late binding?”, etc. > > If Java developers drink coffee, then what is the model beverage for > haskellers? > > “Psyllium Husk” fits the role, because besides phonetic similarities, the > beverage is lazy (the recipe is simple - mix powder with water) and > immutable (goes through the intestinal tract largely unaltered). Plus it > is > far off mainstream. > > -- Message from Stanford University: Folding at home What if you could share your unused computer power to help find a cure? In just 5 minutes you can join the world's biggest networked computer and get us closer sooner. Watch the video. https://foldingathome.org/ -- http://Van.Tuyl.eu https://HenkJanvanTuyl.werkaandemuur.nl/ https://sfeeraandemuur.nl/winkel/nekutimo/ https://github.com/HJvT https://web.archive.org/web/20201109033750/members.chello.nl/hjgtuyl/tourdemonad.html https://web.archive.org/web/20201111212601/http://members.chello.nl/hjgtuyl/computing/EWD1056.html Haskell programming -- From jcb+hc at julianbradfield.org Mon Apr 4 09:03:11 2022 From: jcb+hc at julianbradfield.org (Julian Bradfield) Date: Mon, 4 Apr 2022 10:03:11 +0100 (BST) Subject: [Haskell-cafe] =?utf-8?q?RFC=3A_removing_=E2=80=9Calternative_ins?= =?utf-8?q?tallation_methods=E2=80=9D_from_haskell=2Eorg_=28or_finding_the?= =?utf-8?q?m_owners=29?= References: Message-ID: On 2022-04-03, MigMit wrote: > I think I remember myself as an inexperienced user. I might've walked away from Haskell, if I was given an instruction like "to install thing X, first install thing A, then use it to install think K, and then use that to install thing X". The longer the way between becoming curious about something and actually producing an executable, the less new users you have. Hear, hear. We use Haskell in our first-year course. Almost all students turn up with bog-standard commodity hardware: Windows laptops, Macs, or Chromebooks, with a small proportion of Linux laptops (those people are usually ok). Every year it takes the first two weeks of semester to handhold them all through the process of getting Haskell installed and working. I don't do Windows or Mac, so I don't even know why some (but not all) have problems - but they do. They don't have the choice to walk away, but it wastes valuable learning time, and gives a negative impression. Some of them then find out that they like Haskell, and some that they hate it - I suspect more would like it if they weren't put off by the initial hurdle of getting the damn thing working at all. Having a one-click install for the popular architectures would do a lot for new users, especially if it includes popular stuff like QuickCheck (I suppose QuickCheck is popular - I don't do Haskell, I just have to tutor it:) ) From tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk Mon Apr 4 13:28:56 2022 From: tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk (Tom Ellis) Date: Mon, 4 Apr 2022 14:28:56 +0100 Subject: [Haskell-cafe] =?utf-8?q?RFC=3A_removing_=E2=80=9Calternative_ins?= =?utf-8?q?tallation_methods=E2=80=9D_from_haskell=2Eorg_=28or_finding_the?= =?utf-8?q?m_owners=29?= In-Reply-To: References: Message-ID: On Mon, Apr 04, 2022 at 10:03:11AM +0100, Julian Bradfield wrote: > On 2022-04-03, MigMit wrote: > > I think I remember myself as an inexperienced user. I might've > > walked away from Haskell, if I was given an instruction like "to > > install thing X, first install thing A, then use it to install > > think K, and then use that to install thing X". The longer the way > > between becoming curious about something and actually producing an > > executable, the less new users you have. > > We use Haskell in our first-year course. Almost all students turn up > with bog-standard commodity hardware: Windows laptops, Macs, or > Chromebooks, with a small proportion of Linux laptops (those people > are usually ok). Every year it takes the first two weeks of semester > to handhold them all through the process of getting Haskell installed > and working. I don't do Windows or Mac, so I don't even know why some > (but not all) have problems - but they do. > They don't have the choice to walk away, but it wastes valuable > learning time, and gives a negative impression. Some of them then find > out that they like Haskell, and some that they hate it - I suspect > more would like it if they weren't put off by the initial hurdle of > getting the damn thing working at all. > > Having a one-click install for the popular architectures would do a > lot for new users, especially if it includes popular stuff like > QuickCheck (I suppose QuickCheck is popular - I don't do Haskell, I > just have to tutor it:) ) Hello Julian, Thanks very much for sharing this perspective. The more different perspectives we hear the better idea we have of how to improve the situation for a broad range of users and use cases. However, I'm a bit puzzled by the experience of your students. The Downloads page[1] already contains a link to ghcup which is a one-click installer (or rather a one-click-to-paste-into-the-terminal installer) for the popular architectures. It should work as well on Windows and Mac as it does on Linux. If there is any way you could share more detailed experience reports with us I would be very grateful. Perhaps there's something we can fix or improve, but I don't know yet what! Tom [1] https://www.haskell.org/downloads/ From keith.wygant at gmail.com Mon Apr 4 13:44:24 2022 From: keith.wygant at gmail.com (Keith) Date: Mon, 04 Apr 2022 13:44:24 +0000 Subject: [Haskell-cafe] =?utf-8?q?RFC=3A_removing_=E2=80=9Calternative_ins?= =?utf-8?q?tallation_methods=E2=80=9D_from_haskell=2Eorg_=28or_find?= =?utf-8?q?ing_them_owners=29?= In-Reply-To: References: Message-ID: <84F6B261-836D-4F02-A092-EADBC88F0AD3@gmail.com> >However, I'm a bit puzzled by the experience of your students. The >Downloads page[1] already contains a link to ghcup which is a >one-click installer (or rather a one-click-to-paste-into-the-terminal >installer) for the popular architectures. It should work as well on >Windows and Mac as it does on Linux. Sad to say, but even among computer science students there is a world of difference between a '1 click' installer and one line of shell code to run. Sent from my phone with K-9 Mail. On 4 April 2022 13:28:56 UTC, Tom Ellis wrote: >On Mon, Apr 04, 2022 at 10:03:11AM +0100, Julian Bradfield wrote: >> On 2022-04-03, MigMit wrote: >> > I think I remember myself as an inexperienced user. I might've >> > walked away from Haskell, if I was given an instruction like "to >> > install thing X, first install thing A, then use it to install >> > think K, and then use that to install thing X". The longer the way >> > between becoming curious about something and actually producing an >> > executable, the less new users you have. >> >> We use Haskell in our first-year course. Almost all students turn up >> with bog-standard commodity hardware: Windows laptops, Macs, or >> Chromebooks, with a small proportion of Linux laptops (those people >> are usually ok). Every year it takes the first two weeks of semester >> to handhold them all through the process of getting Haskell installed >> and working. I don't do Windows or Mac, so I don't even know why some >> (but not all) have problems - but they do. >> They don't have the choice to walk away, but it wastes valuable >> learning time, and gives a negative impression. Some of them then find >> out that they like Haskell, and some that they hate it - I suspect >> more would like it if they weren't put off by the initial hurdle of >> getting the damn thing working at all. >> >> Having a one-click install for the popular architectures would do a >> lot for new users, especially if it includes popular stuff like >> QuickCheck (I suppose QuickCheck is popular - I don't do Haskell, I >> just have to tutor it:) ) > >Hello Julian, > >Thanks very much for sharing this perspective. The more different >perspectives we hear the better idea we have of how to improve the >situation for a broad range of users and use cases. > >However, I'm a bit puzzled by the experience of your students. The >Downloads page[1] already contains a link to ghcup which is a >one-click installer (or rather a one-click-to-paste-into-the-terminal >installer) for the popular architectures. It should work as well on >Windows and Mac as it does on Linux. > >If there is any way you could share more detailed experience reports >with us I would be very grateful. Perhaps there's something we can >fix or improve, but I don't know yet what! > >Tom > > > >[1] https://www.haskell.org/downloads/ >_______________________________________________ >Haskell-Cafe mailing list >To (un)subscribe, modify options or view archives go to: >http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >Only members subscribed via the mailman list are allowed to post. From allbery.b at gmail.com Mon Apr 4 13:49:46 2022 From: allbery.b at gmail.com (Brandon Allbery) Date: Mon, 4 Apr 2022 09:49:46 -0400 Subject: [Haskell-cafe] =?utf-8?q?RFC=3A_removing_=E2=80=9Calternative_ins?= =?utf-8?q?tallation_methods=E2=80=9D_from_haskell=2Eorg_=28or_find?= =?utf-8?q?ing_them_owners=29?= In-Reply-To: <84F6B261-836D-4F02-A092-EADBC88F0AD3@gmail.com> References: <84F6B261-836D-4F02-A092-EADBC88F0AD3@gmail.com> Message-ID: They also mentioned Chromebooks, for which a one-line-paste installer requires jailbreaking (and not all Chromebooks can be jailbroken even if students are willing to go that direction). Then again, I suspect any compiler without a full IDE is a loss in that situation. As to Macs, I believe we've had a few problems with incorrectly signed packages which require some extra steps? And at least one report of the (long and ugly) paste for Windows Powershell not working. On Mon, Apr 4, 2022 at 9:45 AM Keith wrote: > > >However, I'm a bit puzzled by the experience of your students. The > >Downloads page[1] already contains a link to ghcup which is a > >one-click installer (or rather a one-click-to-paste-into-the-terminal > >installer) for the popular architectures. It should work as well on > >Windows and Mac as it does on Linux. > > Sad to say, but even among computer science students there is a world of difference between a '1 click' installer and one line of shell code to run. > > Sent from my phone with K-9 Mail. > > On 4 April 2022 13:28:56 UTC, Tom Ellis wrote: > >On Mon, Apr 04, 2022 at 10:03:11AM +0100, Julian Bradfield wrote: > >> On 2022-04-03, MigMit wrote: > >> > I think I remember myself as an inexperienced user. I might've > >> > walked away from Haskell, if I was given an instruction like "to > >> > install thing X, first install thing A, then use it to install > >> > think K, and then use that to install thing X". The longer the way > >> > between becoming curious about something and actually producing an > >> > executable, the less new users you have. > >> > >> We use Haskell in our first-year course. Almost all students turn up > >> with bog-standard commodity hardware: Windows laptops, Macs, or > >> Chromebooks, with a small proportion of Linux laptops (those people > >> are usually ok). Every year it takes the first two weeks of semester > >> to handhold them all through the process of getting Haskell installed > >> and working. I don't do Windows or Mac, so I don't even know why some > >> (but not all) have problems - but they do. > >> They don't have the choice to walk away, but it wastes valuable > >> learning time, and gives a negative impression. Some of them then find > >> out that they like Haskell, and some that they hate it - I suspect > >> more would like it if they weren't put off by the initial hurdle of > >> getting the damn thing working at all. > >> > >> Having a one-click install for the popular architectures would do a > >> lot for new users, especially if it includes popular stuff like > >> QuickCheck (I suppose QuickCheck is popular - I don't do Haskell, I > >> just have to tutor it:) ) > > > >Hello Julian, > > > >Thanks very much for sharing this perspective. The more different > >perspectives we hear the better idea we have of how to improve the > >situation for a broad range of users and use cases. > > > >However, I'm a bit puzzled by the experience of your students. The > >Downloads page[1] already contains a link to ghcup which is a > >one-click installer (or rather a one-click-to-paste-into-the-terminal > >installer) for the popular architectures. It should work as well on > >Windows and Mac as it does on Linux. > > > >If there is any way you could share more detailed experience reports > >with us I would be very grateful. Perhaps there's something we can > >fix or improve, but I don't know yet what! > > > >Tom > > > > > > > >[1] https://www.haskell.org/downloads/ > >_______________________________________________ > >Haskell-Cafe mailing list > >To (un)subscribe, modify options or view archives go to: > >http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > >Only members subscribed via the mailman list are allowed to post. > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -- brandon s allbery kf8nh allbery.b at gmail.com From tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk Mon Apr 4 13:51:17 2022 From: tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk (Tom Ellis) Date: Mon, 4 Apr 2022 14:51:17 +0100 Subject: [Haskell-cafe] =?utf-8?q?RFC=3A_removing_=E2=80=9Calternative_ins?= =?utf-8?q?tallation_methods=E2=80=9D_from_haskell=2Eorg_=28or_finding_the?= =?utf-8?q?m_owners=29?= In-Reply-To: <84F6B261-836D-4F02-A092-EADBC88F0AD3@gmail.com> References: <84F6B261-836D-4F02-A092-EADBC88F0AD3@gmail.com> Message-ID: On Mon, Apr 04, 2022 at 01:44:24PM +0000, Keith wrote: > >However, I'm a bit puzzled by the experience of your students. The > >Downloads page[1] already contains a link to ghcup which is a > >one-click installer (or rather a one-click-to-paste-into-the-terminal > >installer) for the popular architectures. It should work as well on > >Windows and Mac as it does on Linux. > > Sad to say, but even among computer science students there is a > world of difference between a '1 click' installer and one line of > shell code to run. I can certainly believe that, but without more precise details of exactly what form that difference takes I can't do much about improving the situation. Tom From lists at richarde.dev Mon Apr 4 14:47:53 2022 From: lists at richarde.dev (Richard Eisenberg) Date: Mon, 4 Apr 2022 14:47:53 +0000 Subject: [Haskell-cafe] =?utf-8?q?RFC=3A_removing_=E2=80=9Calternative_ins?= =?utf-8?q?tallation_methods=E2=80=9D_from_haskell=2Eorg_=28or_finding_the?= =?utf-8?q?m_owners=29?= In-Reply-To: References: <84F6B261-836D-4F02-A092-EADBC88F0AD3@gmail.com> Message-ID: <010f017ff50be999-db998b15-d85a-4649-b97e-6603525aa684-000000@us-east-2.amazonses.com> For what it's worth, I completely agree that installation problems are very bad for students, along at least two axes: students can never seem to install software, and their inability to install software gives them a negative outlook on the course. If we wish to optimize for students, I think the only way forward is to get something in the e.g. Mac App Store. They know how to install from their system's app store. (I don't know what Windows uses.) Or equivalently their distribution's package manager. Anything beyond that is a struggle. This is not an easy problem to fix! To me, the real solution is to have a fully-featured web IDE. A professor might encourage students to install locally, but with a web IDE backstop, the student's failure to install won't stop them from making progress -- and maybe even the professor delays encouraging the local install by a few weeks, to get students motivated by showing them how fun Haskell is. Developing a web IDE is beyond the scope of this discussion. But maybe this post suggests that OS-oriented packagers are important and should get a mention on the page. It could be something as simple as "Your system's package manager or app store may also have installers for the Haskell toolchain, maintained by community contributors." at the bottom of the page. Richard > On Apr 4, 2022, at 9:51 AM, Tom Ellis wrote: > > On Mon, Apr 04, 2022 at 01:44:24PM +0000, Keith wrote: >>> However, I'm a bit puzzled by the experience of your students. The >>> Downloads page[1] already contains a link to ghcup which is a >>> one-click installer (or rather a one-click-to-paste-into-the-terminal >>> installer) for the popular architectures. It should work as well on >>> Windows and Mac as it does on Linux. >> >> Sad to say, but even among computer science students there is a >> world of difference between a '1 click' installer and one line of >> shell code to run. > > I can certainly believe that, but without more precise details of > exactly what form that difference takes I can't do much about > improving the situation. > > Tom > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. From allbery.b at gmail.com Mon Apr 4 14:57:22 2022 From: allbery.b at gmail.com (Brandon Allbery) Date: Mon, 4 Apr 2022 10:57:22 -0400 Subject: [Haskell-cafe] =?utf-8?q?RFC=3A_removing_=E2=80=9Calternative_ins?= =?utf-8?q?tallation_methods=E2=80=9D_from_haskell=2Eorg_=28or_find?= =?utf-8?q?ing_them_owners=29?= In-Reply-To: <010f017ff50be999-db998b15-d85a-4649-b97e-6603525aa684-000000@us-east-2.amazonses.com> References: <84F6B261-836D-4F02-A092-EADBC88F0AD3@gmail.com> <010f017ff50be999-db998b15-d85a-4649-b97e-6603525aa684-000000@us-east-2.amazonses.com> Message-ID: There is already a good Haskell toolchain installer for VS Code, which is hopefully already available in a suitable form. Not a web IDE, but might start to address some of these problems. As for web IDEs, I believe tomsmeding has something in the works that might also be a good start. On Mon, Apr 4, 2022 at 10:53 AM Richard Eisenberg wrote: > > For what it's worth, I completely agree that installation problems are very bad for students, along at least two axes: students can never seem to install software, and their inability to install software gives them a negative outlook on the course. > > If we wish to optimize for students, I think the only way forward is to get something in the e.g. Mac App Store. They know how to install from their system's app store. (I don't know what Windows uses.) Or equivalently their distribution's package manager. Anything beyond that is a struggle. This is not an easy problem to fix! To me, the real solution is to have a fully-featured web IDE. A professor might encourage students to install locally, but with a web IDE backstop, the student's failure to install won't stop them from making progress -- and maybe even the professor delays encouraging the local install by a few weeks, to get students motivated by showing them how fun Haskell is. > > Developing a web IDE is beyond the scope of this discussion. But maybe this post suggests that OS-oriented packagers are important and should get a mention on the page. It could be something as simple as "Your system's package manager or app store may also have installers for the Haskell toolchain, maintained by community contributors." at the bottom of the page. > > Richard > > > On Apr 4, 2022, at 9:51 AM, Tom Ellis wrote: > > > > On Mon, Apr 04, 2022 at 01:44:24PM +0000, Keith wrote: > >>> However, I'm a bit puzzled by the experience of your students. The > >>> Downloads page[1] already contains a link to ghcup which is a > >>> one-click installer (or rather a one-click-to-paste-into-the-terminal > >>> installer) for the popular architectures. It should work as well on > >>> Windows and Mac as it does on Linux. > >> > >> Sad to say, but even among computer science students there is a > >> world of difference between a '1 click' installer and one line of > >> shell code to run. > > > > I can certainly believe that, but without more precise details of > > exactly what form that difference takes I can't do much about > > improving the situation. > > > > Tom > > _______________________________________________ > > Haskell-Cafe mailing list > > To (un)subscribe, modify options or view archives go to: > > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > Only members subscribed via the mailman list are allowed to post. > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -- brandon s allbery kf8nh allbery.b at gmail.com From migmit at gmail.com Mon Apr 4 14:58:33 2022 From: migmit at gmail.com (MigMit) Date: Mon, 4 Apr 2022 16:58:33 +0200 Subject: [Haskell-cafe] =?utf-8?q?RFC=3A_removing_=E2=80=9Calternative_ins?= =?utf-8?q?tallation_methods=E2=80=9D_from_haskell=2Eorg_=28or_finding_the?= =?utf-8?q?m_owners=29?= In-Reply-To: <010f017ff50be999-db998b15-d85a-4649-b97e-6603525aa684-000000@us-east-2.amazonses.com> References: <84F6B261-836D-4F02-A092-EADBC88F0AD3@gmail.com> <010f017ff50be999-db998b15-d85a-4649-b97e-6603525aa684-000000@us-east-2.amazonses.com> Message-ID: <1D8BA1BB-13B6-4EC5-8F40-498E657E8853@gmail.com> Web IDEs are useful sometimes, but they do not actually produce an executable. Having something you can ONLY run on the Web is not a great thing for a newbie. At the same time, a simple installer (e.g., DMG on Mac) that can be clicked through is usually a familiar thing, IMHO. App Store would be nice for a GUI app, but I'm not sure a compiler can get there at all. > On 4 Apr 2022, at 16:47, Richard Eisenberg wrote: > > For what it's worth, I completely agree that installation problems are very bad for students, along at least two axes: students can never seem to install software, and their inability to install software gives them a negative outlook on the course. > > If we wish to optimize for students, I think the only way forward is to get something in the e.g. Mac App Store. They know how to install from their system's app store. (I don't know what Windows uses.) Or equivalently their distribution's package manager. Anything beyond that is a struggle. This is not an easy problem to fix! To me, the real solution is to have a fully-featured web IDE. A professor might encourage students to install locally, but with a web IDE backstop, the student's failure to install won't stop them from making progress -- and maybe even the professor delays encouraging the local install by a few weeks, to get students motivated by showing them how fun Haskell is. > > Developing a web IDE is beyond the scope of this discussion. But maybe this post suggests that OS-oriented packagers are important and should get a mention on the page. It could be something as simple as "Your system's package manager or app store may also have installers for the Haskell toolchain, maintained by community contributors." at the bottom of the page. > > Richard > >> On Apr 4, 2022, at 9:51 AM, Tom Ellis wrote: >> >> On Mon, Apr 04, 2022 at 01:44:24PM +0000, Keith wrote: >>>> However, I'm a bit puzzled by the experience of your students. The >>>> Downloads page[1] already contains a link to ghcup which is a >>>> one-click installer (or rather a one-click-to-paste-into-the-terminal >>>> installer) for the popular architectures. It should work as well on >>>> Windows and Mac as it does on Linux. >>> >>> Sad to say, but even among computer science students there is a >>> world of difference between a '1 click' installer and one line of >>> shell code to run. >> >> I can certainly believe that, but without more precise details of >> exactly what form that difference takes I can't do much about >> improving the situation. >> >> Tom >> _______________________________________________ >> Haskell-Cafe mailing list >> To (un)subscribe, modify options or view archives go to: >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> Only members subscribed via the mailman list are allowed to post. > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. From goemansrowan at gmail.com Wed Apr 6 19:29:20 2022 From: goemansrowan at gmail.com (rowan goemans) Date: Wed, 6 Apr 2022 21:29:20 +0200 Subject: [Haskell-cafe] Typechecker complains about untouchable types Message-ID: Hello everyone, I'm running into a type error I don't quite understand why it's happening. Consider this type class and function: ``` class KnownNat n => F (n :: Nat) foo :: forall n. F n => (F n => Proxy n -> Proxy n) -> Int foo f = let _ = f (Proxy @n) in 0 ``` This typechecks with no issues. But once I add an LTE constraint to the type class it won't typecheck  and complains about an untouchable type. ``` class (KnownNat n, 1 <= n) => F (n :: Nat) foo :: forall n. F n => (F n => Proxy n -> Proxy n) -> Int foo f = let _ = f (Proxy @n) in 0 ``` with this error: ``` test.hs:11:8: error:     • Could not deduce (F n0)       from the context: F n         bound by the type signature for:                    foo :: forall (n :: Nat). F n => (F n => Proxy n -> Proxy n) -> Int         at test.hs:11:8-58       The type variable ‘n0’ is ambiguous     • In the ambiguity check for ‘foo’       To defer the ambiguity check to use sites, enable AllowAmbiguousTypes       In the type signature:         foo :: forall n. F n => (F n => Proxy n -> Proxy n) -> Int     | 111 | foo :: forall n. F n => (F n => Proxy n -> Proxy n) -> Int     |        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ test.hs:11:8: error:     • Couldn't match type ‘n0’ with ‘n’         ‘n0’ is untouchable           inside the constraints: F n0           bound by a type expected by the context:                      F n0 => Proxy n0 -> Proxy n0           at test.hs:11:8-58       ‘n’ is a rigid type variable bound by         the type signature for:           foo :: forall (n :: Nat). F n => (F n => Proxy n -> Proxy n) -> Int         at test.hs:11:8-58       Expected type: Proxy n0 -> Proxy n0         Actual type: Proxy n -> Proxy n     • In the ambiguity check for ‘foo’       To defer the ambiguity check to use sites, enable AllowAmbiguousTypes       In the type signature:         foo :: forall n. F n => (F n => Proxy n -> Proxy n) -> Int     | 111 | foo :: forall n. F n => (F n => Proxy n -> Proxy n) -> Int     |        ^^^^^^^^^^^^^^^^^^^^ ``` Interestingly adding an equality constraint on `n` does also work: ``` class (KnownNat n, 1 ~ n) => F (n :: Nat) foo :: forall n. F n => (F n => Proxy n -> Proxy n) -> Int foo f = let _ = f (Proxy @n) in 0 ``` Anyone have any clue what is going on here? Best regards, Rowan Goemans From ruben.astud at gmail.com Thu Apr 7 05:06:20 2022 From: ruben.astud at gmail.com (Ruben Astudillo) Date: Thu, 7 Apr 2022 01:06:20 -0400 Subject: [Haskell-cafe] [ANN] Jacinda 1.0.0.0 - a functional text processing language complementing sed, awk, etc. In-Reply-To: References: Message-ID: <34a087b4-3535-1d79-27b6-cc1118a41110@gmail.com> This is great! I have been playing with this for the last two days. It certainly will replace `gawk` on day to day for me. These one-liners pack surprising amount of power. Congrats! -- Rubén. (pgp: 1E88 3AC4 89EB FA22) On 03-04-22 15:05, Vanessa McHale wrote: > Hi all, > > I have released the 1.0.0.0 version of Jacinda, an expression-oriented > text processing language for the command-line. > > You can find it here (Linux, mainly): > https://github.com/vmchale/jacinda/releases/tag/1.0.0.0 > > Cheers, > Vanessa McHale From viercc at gmail.com Thu Apr 7 12:08:22 2022 From: viercc at gmail.com (=?UTF-8?B?5a6u6YeM5rS45Y+4?=) Date: Thu, 7 Apr 2022 21:08:22 +0900 Subject: [Haskell-cafe] Typechecker complains about untouchable types In-Reply-To: References: Message-ID: Hi rowan, This seems like a bug (at least inconvenience) in the constraint solver. But it's already fixed to accept both versions in the newer releases of GHC. I've checked that ghc-8.8.3 and ghc-8.10.7 rejects with the type error you reported, while ghc-9.0.1 or newer accepts without any error. I think there's a filed issue in the issue tracker, but sorry I couldn't find. -- /* Koji Miyazato */ From david.feuer at gmail.com Thu Apr 7 21:24:56 2022 From: david.feuer at gmail.com (David Feuer) Date: Thu, 7 Apr 2022 17:24:56 -0400 Subject: [Haskell-cafe] Typechecker complains about untouchable types In-Reply-To: References: Message-ID: Trying to actually *call* the function without an explicit type argument will still fail. On Thu, Apr 7, 2022 at 8:09 AM 宮里洸司 wrote: > > Hi rowan, > > This seems like a bug (at least inconvenience) in the constraint > solver. But it's already > fixed to accept both versions in the newer releases of GHC. > > I've checked that ghc-8.8.3 and ghc-8.10.7 rejects with the type error > you reported, > while ghc-9.0.1 or newer accepts without any error. > > I think there's a filed issue in the issue tracker, but sorry I couldn't find. > > -- > /* Koji Miyazato */ > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. From W.S.Swierstra at uu.nl Fri Apr 8 09:40:13 2022 From: W.S.Swierstra at uu.nl (Swierstra, W.S. (Wouter)) Date: Fri, 8 Apr 2022 09:40:13 +0000 Subject: [Haskell-cafe] Utrecht Summer School on Advanced Functional Programming 2022 Message-ID: <786fcbd9-187c-e005-2f2b-419e2b20945a@uu.nl> # Call for Participation SUMMER SCHOOL ON ADVANCED FUNCTIONAL PROGRAMMING Utrecht, the Netherlands, 04 July – 08 July 2022 http://www.afp.school ## ABOUT The Advanced Functional Programming summer school has been running for more than ten years. We aim to educate aspiring Haskell programmers beyond the basic material covered by many textbooks. After running remotely for the past two years, we're thrilled to announce that this year's edition will take place on site in Utrecht. We are monitoring the pandemic closely - and will make contingency plans if we cannot meet in person; at the moment, we do not have plans for remote participation. The lectures will cover several more advanced topics regarding the theory and practice of Haskell programming, including topics such as: * lambda calculus; * monads and monad transformers; * lazy evaluation; * generalized algebraic data types; * type families and type-level programming; * concurrency and parallelism. The summer school consists of a mix of lectures, labs, and a busy social program. ## LECTURERS * Gabriele Keller * Trevor McDonell * Wouter Swierstra ## PREREQUISITES We expect students to have a basic familiarity with Haskell already. You should be able to write recursive functions over algebraic data types, such as lists and trees. There is a great deal of material readily available that covers this material. If you've already started learning Haskell and are looking to take your functional programming skills to the next level, this is the course for you. ## DATES Soft registration deadline: 24 June, 2022 School: 04 July – 08 July 2022 ## COSTS 750 euro - Profession registration only 250 euro - Student registration fee 200 euro - Housing fee We will charge a registration fee of 750 euros (or 250 euros for students) to cover our expenses. If this is problematic for you for any reason at all, please email the organisers and we can try to offer you a discounted rate or a fee waiver. We have a limited number of scholarships or discounts available for students that would not be able to attend otherwise, especially for women and under-represented minorities. ## FURTHER INFORMATION Further information, including instructions on how to register, is available on our website: http://www.afp.school From olf at aatal-apotheke.de Sat Apr 9 20:45:56 2022 From: olf at aatal-apotheke.de (Olaf Klinke) Date: Sat, 09 Apr 2022 22:45:56 +0200 Subject: [Haskell-cafe] ANN: haskell for mathematicians Message-ID: <2d756d3dcf38aeba55181d6b4901c364d623e7c1.camel@aatal-apotheke.de> Dear Café, my monograph "Haskell for Mathematicians" has found a home online: https://hub.darcs.net/olf/haskell_for_mathematicians The intended audience of this course is mathematicians. While there are many (and excellent) introductions and complete books on Haskell available, most of them target programmers. But Haskell, despite being practically useful, is very good at modelling certain branches of mathematics. The aim of this course is to supplement the pen-and-paper mathematics with a more palpable, more interactive variant of exploring mathematical concepts. Each chapter contains exercises and is a self-contained literate haskell file that requires no package dependencies other than those included in a basic Haskell installation. Selected goodies you can find in Haskell for Mathematicians: * Constructive topology via domain semantics of Haskell * Let the compiler verify theorems of intuitionistic logic * Two implementations of exact real numbers: signed-digit and Conway's surreal numbers * Categories (of course!) * Detailed discussion of mathematical properties of monads such as commutative and affine monads * Detailed derivation of a probability measure monad that is actually affine (unlike sampling-based ones) Please use the darcs issue tracker for reporting typos, strange wording or incaccuracies. Also please don't hesitate to point me to existing work that might be worth mentioning or incorporating in the monograph. Cheers Olaf From guthrie at miu.edu Sat Apr 9 22:46:21 2022 From: guthrie at miu.edu (Gregory Guthrie) Date: Sat, 9 Apr 2022 22:46:21 +0000 Subject: [Haskell-cafe] ANN: haskell for mathematicians In-Reply-To: <2d756d3dcf38aeba55181d6b4901c364d623e7c1.camel@aatal-apotheke.de> References: <2d756d3dcf38aeba55181d6b4901c364d623e7c1.camel@aatal-apotheke.de> Message-ID: pdf version? Sent from a small portable device with limited input capabilities! -------- Original message -------- From: Olaf Klinke Date: 4/9/22 3:46 PM (GMT-06:00) To: Haskell Café Subject: [Haskell-cafe] ANN: haskell for mathematicians Dear Café, my monograph "Haskell for Mathematicians" has found a home online: https://hub.darcs.net/olf/haskell_for_mathematicians The intended audience of this course is mathematicians. While there are many (and excellent) introductions and complete books on Haskell available, most of them target programmers. But Haskell, despite being practically useful, is very good at modelling certain branches of mathematics. The aim of this course is to supplement the pen-and-paper mathematics with a more palpable, more interactive variant of exploring mathematical concepts. Each chapter contains exercises and is a self-contained literate haskell file that requires no package dependencies other than those included in a basic Haskell installation. Selected goodies you can find in Haskell for Mathematicians: * Constructive topology via domain semantics of Haskell * Let the compiler verify theorems of intuitionistic logic * Two implementations of exact real numbers: signed-digit and Conway's surreal numbers * Categories (of course!) * Detailed discussion of mathematical properties of monads such as commutative and affine monads * Detailed derivation of a probability measure monad that is actually affine (unlike sampling-based ones) Please use the darcs issue tracker for reporting typos, strange wording or incaccuracies. Also please don't hesitate to point me to existing work that might be worth mentioning or incorporating in the monograph. Cheers Olaf _______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From iblech at web.de Sat Apr 9 23:17:14 2022 From: iblech at web.de (Ingo Blechschmidt) Date: Sun, 10 Apr 2022 01:17:14 +0200 Subject: [Haskell-cafe] ANN: haskell for mathematicians In-Reply-To: <2d756d3dcf38aeba55181d6b4901c364d623e7c1.camel@aatal-apotheke.de> References: <2d756d3dcf38aeba55181d6b4901c364d623e7c1.camel@aatal-apotheke.de> Message-ID: Dear Olaf, On Sat 09 Apr 2022 10:45:56 PM GMT, Olaf Klinke wrote: > my monograph "Haskell for Mathematicians" has found a home online: > https://hub.darcs.net/olf/haskell_for_mathematicians I just had a first look, your monograph looks awesome! Thank you for sharing! In haskell_for_mathematicians.tex, you mention as a further idea that Hask is like a Heyting algebra. Could you elaborate on that point? Are you thinking of types as propositions here? Cheers, Ingo From olf at aatal-apotheke.de Sun Apr 10 19:26:15 2022 From: olf at aatal-apotheke.de (Olaf Klinke) Date: Sun, 10 Apr 2022 21:26:15 +0200 (CEST) Subject: [Haskell-cafe] ANN: haskell for mathematicians Message-ID: >Dear Olaf, > >On Sat 09 Apr 2022 10:45:56 PM GMT, Olaf Klinke wrote: >> my monograph "Haskell for Mathematicians" has found a home online: >> https://hub.darcs.net/olf/haskell_for_mathematicians > >I just had a first look, your monograph looks awesome! Thank you for >sharing! > >In haskell_for_mathematicians.tex, you mention as a further idea that >Hask is like a Heyting algebra. Could you elaborate on that point? Are >you thinking of types as propositions here? > >Cheers, >Ingo Hi Ingo, Types as propositions is dealt with in haskell_for_logicians.lhs. Hask has an arrow that is a right adjoint, just like a Heyting algebra. It is less clear, however, whether the the arrow gives rise to a partial order as it does in Heyting algebras. I am interested in the complete Heyting algebras, a.k.a. frames a.k.a. locales. Many concepts in point-free topology heavily rely on partial orders and lattice theory, so without a good analogue I would not dare declare a similarity. For example, in a Heyting algebra x <= y iff x -> y equals the top element. But then, what is the top element of Hask? Do we declare x <= y if x -> y is inhabited? That seems to collapse all inhabited types. In a future chapter I would like to tell a story around this: In point-free topology (locale theory), there are several inter-definable concepts of sub-object. One of them is a "nucleus", that is an endo-function j with the following properties. x <= y implies j(x) <= j(y) (j is a functor) x <= j(x) (return :: x -> j x) j(j(x)) <= j(x) (join :: j (j x) -> j x) j(x) /\ j(y) <= j(x /\ y) (liftM2 (,) :: j x -> j y -> j (x,y)) In other words: sub-objects of point-free spaces are (strong) monads. In that respect, every monad j is a sub-object of Hask, and indeed it is: It defines the sub-category (Kleisli j). There are more analogues: The identity function is a nucleus and corresponds to the greatest sub-object, and in Hask (Kleisli Identity) is the largest Kleisli category. Nuclei can not be combined easily, and neither can monads. Another interesting question is: What are the "points" of Hask? A point of a locale is a mapping from opens (types of Hask) to Bool that preserves finite products and arbitrary coproducts, where True is considered as the empty product and False as the empty coproduct. How many of such mappings can be defined in Haskell? How would we implement them? As a class? Type family? GADT? The funny thing about locales is that one can have few or no points but still a rich supply of sub-objects. Olaf From keith.wygant at gmail.com Sun Apr 10 19:57:20 2022 From: keith.wygant at gmail.com (Keith) Date: Sun, 10 Apr 2022 19:57:20 +0000 Subject: [Haskell-cafe] ANN: haskell for mathematicians In-Reply-To: References: Message-ID: <2DF5D030-389D-4EA5-8820-75DA5368D201@gmail.com> You've probably heard this before, but `()` and `Void` are often described like the Booleans you refer to, but their algebra is noncommutative. Another interesting Haskell type is `GHC.Exts.Any`. Sent from my phone with K-9 Mail. On 10 April 2022 19:26:15 UTC, Olaf Klinke wrote: >>Dear Olaf, >> >>On Sat 09 Apr 2022 10:45:56 PM GMT, Olaf Klinke wrote: >>> my monograph "Haskell for Mathematicians" has found a home online: >>> https://hub.darcs.net/olf/haskell_for_mathematicians >> >>I just had a first look, your monograph looks awesome! Thank you for >>sharing! >> >>In haskell_for_mathematicians.tex, you mention as a further idea that >>Hask is like a Heyting algebra. Could you elaborate on that point? Are >>you thinking of types as propositions here? >> >>Cheers, >>Ingo > >Hi Ingo, > >Types as propositions is dealt with in haskell_for_logicians.lhs. >Hask has an arrow that is a right adjoint, just like a Heyting algebra. It >is less clear, however, whether the the arrow gives rise to a partial >order as it does in Heyting algebras. I am interested in the complete >Heyting algebras, a.k.a. frames a.k.a. locales. Many concepts in >point-free topology heavily rely on partial orders and lattice theory, so >without a good analogue I would not dare declare a similarity. >For example, in a Heyting algebra x <= y iff x -> y equals the top >element. >But then, what is the top element of Hask? Do we declare x <= y if x -> y >is inhabited? That seems to collapse all inhabited types. > >In a future chapter I would like to tell a story around this: >In point-free topology (locale theory), there are several inter-definable >concepts of sub-object. One of them is a "nucleus", that is an >endo-function j with the following properties. >x <= y implies j(x) <= j(y) (j is a functor) >x <= j(x) (return :: x -> j x) >j(j(x)) <= j(x) (join :: j (j x) -> j x) >j(x) /\ j(y) <= j(x /\ y) (liftM2 (,) :: j x -> j y -> j (x,y)) > >In other words: sub-objects of point-free spaces are (strong) monads. >In that respect, every monad j is a sub-object of Hask, and indeed it is: >It defines the sub-category (Kleisli j). There are more analogues: The >identity function is a nucleus and corresponds to the greatest sub-object, >and in Hask (Kleisli Identity) is the largest Kleisli category. Nuclei can >not be combined easily, and neither can monads. > >Another interesting question is: What are the "points" of Hask? A point of >a locale is a mapping from opens (types of Hask) to Bool that preserves >finite products and arbitrary coproducts, where True is considered as the >empty product and False as the empty coproduct. How many of such mappings >can be defined in Haskell? How would we implement them? As a class? Type >family? GADT? >The funny thing about locales is that one can have few or no points but >still a rich supply of sub-objects. > >Olaf >_______________________________________________ >Haskell-Cafe mailing list >To (un)subscribe, modify options or view archives go to: >http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Tue Apr 12 08:03:34 2022 From: mail at joachim-breitner.de (Joachim Breitner) Date: Tue, 12 Apr 2022 10:03:34 +0200 Subject: [Haskell-cafe] Retro/indie Haskell to appreciate In-Reply-To: References: Message-ID: Hi, Am Sonntag, dem 13.03.2022 um 11:06 -0700 schrieb Vanessa McHale: > I’m looking to appreciate “retro” Haskell projects, things from before > stabilization/company use.  http://www2.informatik.uni-freiburg.de/~thiemann/haskell/WASH/ comes to mind, according to the changelog it started in 2003 and was cabalized in 2006. Cheers, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ From david.feuer at gmail.com Tue Apr 12 13:23:18 2022 From: david.feuer at gmail.com (David Feuer) Date: Tue, 12 Apr 2022 09:23:18 -0400 Subject: [Haskell-cafe] Retro/indie Haskell to appreciate In-Reply-To: References: Message-ID: I think data-aviary is a great example of a light-hearted functional library. I was reminded of its module names by the recent passing of Richard Bird, whom I do not believe was actually involved in its creation. On Sun, Mar 13, 2022, 2:07 PM Vanessa McHale wrote: > I’m looking to appreciate “retro” Haskell projects, things from before > stabilization/company use. > > Such as: > > fgl https://web.engr.oregonstate.edu/~erwig/fgl/haskell/ > > WWWBrowser https://cth.altocumulus.org/~hallgren/wwwbrowser.html > > Balsa/Teak (languages) > http://apt.cs.manchester.ac.uk/projects/tools/balsa/ > > BlueSpec compiler https://github.com/B-Lang-org/bsc > > The CABAL spec (Common Architecture for Building Applications and Tools) > https://www.haskell.org/cabal/proposal/index.html > > Frag (that one Haskell game) https://wiki.haskell.org/Frag > > Hugs string extensions > https://www.haskell.org/hugs/pages/users_guide/here-documents.html > > I guess darcs/c2hs/happy/alex count, they have history! > > Bonus points for > > > - Makefiles to build the project > - Professor-HTML project page > - Hugs support > - Haskell 1.4 etc. support > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From emilypi at cohomolo.gy Wed Apr 13 05:48:33 2022 From: emilypi at cohomolo.gy (Emily Pillmore) Date: Wed, 13 Apr 2022 05:48:33 +0000 Subject: [Haskell-cafe] Retro/indie Haskell to appreciate In-Reply-To: References: Message-ID: *cough* GHC *cough* On Tue, Apr 12, 2022 at 7:23 AM, David Feuer < david.feuer at gmail.com > wrote: > > I think data-aviary is a great example of a light-hearted functional > library. I was reminded of its module names by the recent passing of > Richard Bird, whom I do not believe was actually involved in its creation. > > > On Sun, Mar 13, 2022, 2:07 PM Vanessa McHale < vamchale@ gmail. com ( > vamchale at gmail.com ) > wrote: > > >> I’m looking to appreciate “retro” Haskell projects, things from before >> stabilization/company use. >> >> >> Such as: >> >> >> fgl https:/ / web. engr. oregonstate. edu/ ~erwig/ fgl/ haskell/ ( >> https://web.engr.oregonstate.edu/~erwig/fgl/haskell/ ) >> >> >> WWWBrowser https:/ / cth. altocumulus. org/ ~hallgren/ wwwbrowser. html ( >> https://cth.altocumulus.org/~hallgren/wwwbrowser.html ) >> >> >> Balsa/Teak (languages) http:/ / apt. cs. manchester. ac. uk/ projects/ tools/ >> balsa/ ( http://apt.cs.manchester.ac.uk/projects/tools/balsa/ ) >> >> >> BlueSpec compiler https:/ / github. com/ B-Lang-org/ bsc ( >> https://github.com/B-Lang-org/bsc ) >> >> >> The CABAL spec (Common Architecture for Building Applications and Tools) https:/ >> / www. haskell. org/ cabal/ proposal/ index. html ( >> https://www.haskell.org/cabal/proposal/index.html ) >> >> >> Frag (that one Haskell game) https:/ / wiki. haskell. org/ Frag ( >> https://wiki.haskell.org/Frag ) >> >> >> Hugs string extensions https:/ / www. haskell. org/ hugs/ pages/ users_guide/ >> here-documents. html ( >> https://www.haskell.org/hugs/pages/users_guide/here-documents.html ) >> >> >> I guess darcs/c2hs/happy/alex count, they have history! >> >> >> Bonus points for >> >> >> >> >> * Makefiles to build the project >> * Professor-HTML project page >> * Hugs support >> * Haskell 1.4 etc. support >> >> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> To (un)subscribe, modify options or view archives go to: >> http:/ / mail. haskell. org/ cgi-bin/ mailman/ listinfo/ haskell-cafe ( >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe ) >> Only members subscribed via the mailman list are allowed to post. > > > > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: http:/ / mail. haskell. > org/ cgi-bin/ mailman/ listinfo/ haskell-cafe ( > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe ) Only > members subscribed via the mailman list are allowed to post. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk Wed Apr 13 10:09:55 2022 From: tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk (Tom Ellis) Date: Wed, 13 Apr 2022 11:09:55 +0100 Subject: [Haskell-cafe] The planned monomorphisation of Data.List Message-ID: There is a plan to monomorphise the contents of Data.List. I have written up an executive summary on the GitHub thread where it is being discussed. If you have an opinion that you would like to be taken into account then please leave a comment on that GitHub thread. https://github.com/haskell/core-libraries-committee/issues/22#issuecomment-1094333009 From jasonpshipman at gmail.com Wed Apr 13 13:29:42 2022 From: jasonpshipman at gmail.com (Jason Shipman) Date: Wed, 13 Apr 2022 09:29:42 -0400 Subject: [Haskell-cafe] Retro/indie Haskell to appreciate In-Reply-To: References: Message-ID: <9D82A441-A09A-47BF-8953-1E67A2FC66E1@gmail.com> A coworker showed me old-school HaRP stuff. Pretty wild! https://web.archive.org/web/20100415223450/http://www.cs.chalmers.se/~d00nibro/harp/ https://github.com/seereason/harp ~jship -------------- next part -------------- An HTML attachment was scrubbed... URL: From zemyla at gmail.com Sun Apr 17 01:05:59 2022 From: zemyla at gmail.com (Zemyla) Date: Sat, 16 Apr 2022 20:05:59 -0500 Subject: [Haskell-cafe] Ord/Ix and Bounded? Message-ID: Are there any laws relating Bounded to Ord and Ix? For instance, any reasonable type should say minBound <= x == True for all x maxBound >= x == True for all x inRange (minBound, maxBound) x == True for all x -------------- next part -------------- An HTML attachment was scrubbed... URL: From tanuki at gmail.com Sun Apr 17 01:24:17 2022 From: tanuki at gmail.com (Akhra Gannon) Date: Sat, 16 Apr 2022 18:24:17 -0700 Subject: [Haskell-cafe] Ord/Ix and Bounded? In-Reply-To: References: Message-ID: NaN violates this. Of course floats are rife with broken instances to begin with, but in this case it might be important? On Sat, Apr 16, 2022, 6:06 PM Zemyla wrote: > Are there any laws relating Bounded to Ord and Ix? For instance, any > reasonable type should say > > minBound <= x == True for all x > maxBound >= x == True for all x > inRange (minBound, maxBound) x == True for all x > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tanuki at gmail.com Sun Apr 17 01:29:09 2022 From: tanuki at gmail.com (Akhra Gannon) Date: Sat, 16 Apr 2022 18:29:09 -0700 Subject: [Haskell-cafe] Ord/Ix and Bounded? In-Reply-To: References: Message-ID: Granted Double doesn't have Bounded, but consider a type representing a sigmoid transformation. minBound==0.0, maxBound==1.0, but NaN could still be in play. On Sat, Apr 16, 2022, 6:24 PM Akhra Gannon wrote: > NaN violates this. Of course floats are rife with broken instances to > begin with, but in this case it might be important? > > On Sat, Apr 16, 2022, 6:06 PM Zemyla wrote: > >> Are there any laws relating Bounded to Ord and Ix? For instance, any >> reasonable type should say >> >> minBound <= x == True for all x >> maxBound >= x == True for all x >> inRange (minBound, maxBound) x == True for all x >> >> _______________________________________________ >> Haskell-Cafe mailing list >> To (un)subscribe, modify options or view archives go to: >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> Only members subscribed via the mailman list are allowed to post. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at well-typed.com Sun Apr 17 20:09:58 2022 From: ben at well-typed.com (Ben Gamari) Date: Sun, 17 Apr 2022 16:09:58 -0400 Subject: [Haskell-cafe] Haskell.org outage Message-ID: <87k0bn1nhx.fsf@smart-cactus.org> Hello everyone, Unfortunately Haskell.org, downloads.haskell.org, and hoogle.haskell.org are currently down. We are currently investigating the cause. Updates will be posted as they are available. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From ben at well-typed.com Mon Apr 18 04:59:13 2022 From: ben at well-typed.com (Ben Gamari) Date: Mon, 18 Apr 2022 00:59:13 -0400 Subject: [Haskell-cafe] Haskell.org outage In-Reply-To: <87k0bn1nhx.fsf@smart-cactus.org> References: <87k0bn1nhx.fsf@smart-cactus.org> Message-ID: <87fsmb0yyb.fsf@smart-cactus.org> Ben Gamari writes: > Hello everyone, > > Unfortunately Haskell.org, downloads.haskell.org, and hoogle.haskell.org > are currently down. We are currently investigating the cause. Updates > will be posted as they are available. > A quick update: It sounds as though the outage is due to a hardware issue which our hosting provider is currently investigating but naturally responses are a bit slower than usual due to the holiday. More updates to follow tomorrow. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From lysxia at gmail.com Mon Apr 18 14:51:42 2022 From: lysxia at gmail.com (Li-yao Xia) Date: Mon, 18 Apr 2022 10:51:42 -0400 Subject: [Haskell-cafe] BX 2022 - Call for papers (deadline 14 May) Message-ID: # Tenth International Workshop on Bidirectional Transformations (BX 2022) 8 July 2022, Nantes, France Part of STAF 2022 (5-8 July): https://staf2022.univ-nantes.io/ BX 2022 homepage: http://bx-community.wikidot.com/bx2022:home ## Overview Bidirectional transformations (BX) are a mechanism for maintaining the consistency between two or more related (and heterogeneous) sources of information (e.g., relational databases, software models and code, or any other artefacts following standard or domain-specific formats). The strongest argument in favour of BX is its ability to provide a synchronization mechanism that is guaranteed to be correct by construction. BX has been attracting a wide range of research areas and communities, with prominent presence at top conferences in several different fields (namely databases, programming languages, software engineering, and graph transformation). Nowadays, the fast-growing complexity of software- or data-intensive systems has forced industry and academia to use and investigate different development techniques to manage the many different aspects of the systems. Researchers are actively investigating the use of bidirectional approaches to tackle a diverse set of challenges with various applications including model-driven software development, visualization with direct manipulation, big data, databases, domain-specific languages, serializers, and data transformation, integration and exchange. BX 2022 is a dedicated venue for BX in all relevant fields and is part of a workshop series that was created in order to promote cross-disciplinary research and awareness in the area. As such, since its beginning in 2012, the workshop has rotated between venues in different fields. Papers for BX 2022 can be submitted on EasyChair: https://www.easychair.org/conferences/?conf=bx2022 ## Important Dates - Paper submission: 14 May, 2022 - Author notification: 28 May, 2022 - Workshop: 8 July, 2022 ## Topics The aim of the workshop is to bring together researchers and practitioners, established and new, interested in bx from different perspectives, including but not limited to: - bidirectional programming languages and frameworks - software development with BX - data and model synchronization - view updating - inter-model consistency analysis and repair - data/schema (or model/metamodel) co-evolution - coupled software/model transformations - inversion of transformations and data exchange mappings - domain-specific languages for BX - analysis and classification of requirements for BX - bridging the gap between formal concepts and application scenarios - analysis of efficiency of transformation algorithms and benchmarks - model-driven and model-based approaches - survey and comparison of BX technologies - case studies and tool support - applications and experiences of adopting BX in the real world ## Categories of Submissions Five categories of submissions are considered: 1. Full Research Papers (13-15 pages) - in-depth presentations of novel concepts and results - applications of bx to new domains - survey papers providing novel comparisons between existing bx technologies and approaches, case studies 2. Tool Papers (7-8 pages) - guideline papers presenting best practices for employing a specific bx approach (with a specific tool) - presentation of new tools or substantial improvements to existing ones - qualitative and/or quantitative comparisons of applying different bx approaches and tools 3. Experience Report (7-8 pages) - sharing experiences and lessons learned with bx tools/frameworks/languages - how bx is used in (research/industrial/educational) projects 4. Short Papers (5 pages) - work in progress - small focused contributions - position papers and research perspectives - critical questions and challenges for bx 5. Talk Proposals (2 pages) - proposed lectures about topics of interest for bx - existing work representing relevant contributions for bx - promising contributions that are not mature enough to be proposed as papers of the other categories ## Submission guidelines Papers should use the new CEUR-ART style, single column, available as an Overleaf page or as a zip archive: https://www.overleaf.com/read/gwhxnqcghhdt http://ceur-ws.org/Vol-XXX/CEURART.zip and must be submitted via EasyChair: https://www.easychair.org/conferences/?conf=bx2022 If your submission is not a Full Research Paper, please include the intended submission category in the Title field of EasyChair’s submission form. Tool papers, experience reports and short papers will be mapped to the short paper category in CEUR (having between 5-9 standard pages, 1 standard page = 2500 characters), whereas full research papers will be mapped to the regular paper category in CEUR (having at least 10 standard pages). The bibliography is excluded from the page limits. All papers are expected to be self-contained and well-written. Tool papers are not expected to present novel scientific results, but to document artifacts of interest and share bx experience/best practices with the community. Experience papers are expected to report on lessons learnt from applying bx approaches, languages, tools, and theories to practical application case studies. Extended abstracts should primarily provoke interesting discussion at the workshop and will not be held to the same standard of maturity as regular papers; short papers contain focused results, positions or perspectives that can be presented in full in just a few pages, and that correspondingly contain fewer results and that therefore might not be competitive in the full paper category. Talk proposals are expected to present work that is of particular interest to the community and worth a talk slot at the workshop. We strongly encourage authors to ensure that any (variants of) examples are present in the bx example repository at the time of submission, and, for tool papers, to allow for reproducibility with minimal effort, either via a virtual machine (e.g., via Share) or a dedicated website with relevant artifacts and tool access. All papers will be peer-reviewed by at least three members of the program committee. If a submission is accepted, at least one author is expected to participate in the workshop to present it. Authors of accepted tool paper submissions are also expected to be available to demonstrate their tool at the event. ## Proceedings The workshop proceedings (in a STAF 2022 joint volume for workshops), including all accepted papers (except talk proposals), shall be submitted after the conference to CEUR-WS.org for online publication. Pre-prints of all papers will be available via the workshop website at the beginning of the conference. In case of questions, please contact the PC chairs at bx2022 at easychair.org. Best regards, Li-yao Xia, Vadim Zaytsev, Xiao He From markus.l2ll at gmail.com Tue Apr 19 12:15:09 2022 From: markus.l2ll at gmail.com (=?UTF-8?B?TWFya3VzIEzDpGxs?=) Date: Tue, 19 Apr 2022 15:15:09 +0300 Subject: [Haskell-cafe] Package takeover request for rapid Message-ID: Hi I would like to take over https://hackage.haskell.org/package/rapid The author of the package Ertugrul Söylemez, once an active member of the community perhaps best known for netwire, passed away in 2018. [1] The work required for the package thus far, and for which I've kept a fork for, is to bump version bounds as GHCs progress. [1] https://github.com/esoeylemez/rapid/pull/2#issuecomment-427065739 -- Markus Läll From andreas.abel at ifi.lmu.de Tue Apr 19 12:52:57 2022 From: andreas.abel at ifi.lmu.de (Andreas Abel) Date: Tue, 19 Apr 2022 14:52:57 +0200 Subject: [Haskell-cafe] Package takeover request for rapid In-Reply-To: References: Message-ID: Hello Markus, thanks for the initiative! The takeover is probably fine. It might be contested by other applicants, but there aren't really any stakeholders on the source code of rapid. As far as github tells me, the code was single-handedly written by the now passed-away author. Maybe we should wait the suggested 2 weeks for any contestants before we finalize the takeover. You will need help to get added to https://hackage.haskell.org/package/rapid/maintainers/ by one of the hackage admins (CCed). You would likely have to move the code to another github account, would you? Cheers, Andreas (in my role as a hackage trustee) P.S.: I bumped the base-bound of rapid on hackage to ease building with newer GHCs. On 2022-04-19 14:15, Markus Läll wrote: > Hi > > I would like to take over https://hackage.haskell.org/package/rapid > > The author of the package Ertugrul Söylemez, once an active member of > the community perhaps best known for netwire, passed away in 2018. [1] > The work required for the package thus far, and for which I've kept a > fork for, is to bump version bounds as GHCs progress. > > [1] https://github.com/esoeylemez/rapid/pull/2#issuecomment-427065739 > From markus.l2ll at gmail.com Tue Apr 19 14:01:10 2022 From: markus.l2ll at gmail.com (=?UTF-8?B?TWFya3VzIEzDpGxs?=) Date: Tue, 19 Apr 2022 17:01:10 +0300 Subject: [Haskell-cafe] Package takeover request for rapid In-Reply-To: References: Message-ID: Hi Andreas, Yup, let's wait the two weeks. By default I'd maintain it here: https://github.com/eyeinsky/rapid. Are there any other options (a github organization perhaps)? On Tue, Apr 19, 2022 at 3:53 PM Andreas Abel wrote: > > Hello Markus, > > thanks for the initiative! > > The takeover is probably fine. It might be contested by other > applicants, but there aren't really any stakeholders on the source code > of rapid. As far as github tells me, the code was single-handedly > written by the now passed-away author. > > Maybe we should wait the suggested 2 weeks for any contestants before we > finalize the takeover. > > You will need help to get added to > > https://hackage.haskell.org/package/rapid/maintainers/ > > by one of the hackage admins (CCed). > > You would likely have to move the code to another github account, would you? > > Cheers, > Andreas (in my role as a hackage trustee) > > P.S.: I bumped the base-bound of rapid on hackage to ease building with > newer GHCs. > > On 2022-04-19 14:15, Markus Läll wrote: > > Hi > > > > I would like to take over https://hackage.haskell.org/package/rapid > > > > The author of the package Ertugrul Söylemez, once an active member of > > the community perhaps best known for netwire, passed away in 2018. [1] > > The work required for the package thus far, and for which I've kept a > > fork for, is to bump version bounds as GHCs progress. > > > > [1] https://github.com/esoeylemez/rapid/pull/2#issuecomment-427065739 > > -- Markus Läll From david.feuer at gmail.com Tue Apr 19 16:00:27 2022 From: david.feuer at gmail.com (David Feuer) Date: Tue, 19 Apr 2022 12:00:27 -0400 Subject: [Haskell-cafe] Package takeover request for rapid In-Reply-To: References: Message-ID: I always support using a GitHub organization, especially if the package is actually used. You can even make one just for the package. An organization can have multiple owners, providing redundancy if one of them leaves ... or dies. On Tue, Apr 19, 2022, 10:02 AM Markus Läll wrote: > Hi Andreas, > > Yup, let's wait the two weeks. > > By default I'd maintain it here: https://github.com/eyeinsky/rapid. > Are there any other options (a github organization perhaps)? > > On Tue, Apr 19, 2022 at 3:53 PM Andreas Abel > wrote: > > > > Hello Markus, > > > > thanks for the initiative! > > > > The takeover is probably fine. It might be contested by other > > applicants, but there aren't really any stakeholders on the source code > > of rapid. As far as github tells me, the code was single-handedly > > written by the now passed-away author. > > > > Maybe we should wait the suggested 2 weeks for any contestants before we > > finalize the takeover. > > > > You will need help to get added to > > > > https://hackage.haskell.org/package/rapid/maintainers/ > > > > by one of the hackage admins (CCed). > > > > You would likely have to move the code to another github account, would > you? > > > > Cheers, > > Andreas (in my role as a hackage trustee) > > > > P.S.: I bumped the base-bound of rapid on hackage to ease building with > > newer GHCs. > > > > On 2022-04-19 14:15, Markus Läll wrote: > > > Hi > > > > > > I would like to take over https://hackage.haskell.org/package/rapid > > > > > > The author of the package Ertugrul Söylemez, once an active member of > > > the community perhaps best known for netwire, passed away in 2018. [1] > > > The work required for the package thus far, and for which I've kept a > > > fork for, is to bump version bounds as GHCs progress. > > > > > > [1] https://github.com/esoeylemez/rapid/pull/2#issuecomment-427065739 > > > > > > > -- > Markus Läll > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From andreas.abel at ifi.lmu.de Wed Apr 20 12:03:46 2022 From: andreas.abel at ifi.lmu.de (Andreas Abel) Date: Wed, 20 Apr 2022 14:03:46 +0200 Subject: [Haskell-cafe] Package takeover request for rapid In-Reply-To: References: Message-ID: <858d6ff1-ee5c-41e2-e695-92334e03dc80@ifi.lmu.de> > By default I'd maintain it here: https://github.com/eyeinsky/rapid. At the least, this would need an issue tracker... > Are there any other options (a github organization perhaps)? Personally, I prefer maintaining third-party packages on github organizations (see e.g. https://github.com/blaze-builder ). It is easier to co-maintain and to install new maintainers. Github also offers transfer of repositories, but this has to be done by the owner. Unfortunately, since Ertugrul passed away, it might be difficult to transfer the whole repository (with issues etc.). Cheers, Andreas On 2022-04-19 16:01, Markus Läll wrote: > Hi Andreas, > > Yup, let's wait the two weeks. > > By default I'd maintain it here: https://github.com/eyeinsky/rapid. > Are there any other options (a github organization perhaps)? > > On Tue, Apr 19, 2022 at 3:53 PM Andreas Abel wrote: >> >> Hello Markus, >> >> thanks for the initiative! >> >> The takeover is probably fine. It might be contested by other >> applicants, but there aren't really any stakeholders on the source code >> of rapid. As far as github tells me, the code was single-handedly >> written by the now passed-away author. >> >> Maybe we should wait the suggested 2 weeks for any contestants before we >> finalize the takeover. >> >> You will need help to get added to >> >> https://hackage.haskell.org/package/rapid/maintainers/ >> >> by one of the hackage admins (CCed). >> >> You would likely have to move the code to another github account, would you? >> >> Cheers, >> Andreas (in my role as a hackage trustee) >> >> P.S.: I bumped the base-bound of rapid on hackage to ease building with >> newer GHCs. >> >> On 2022-04-19 14:15, Markus Läll wrote: >>> Hi >>> >>> I would like to take over https://hackage.haskell.org/package/rapid >>> >>> The author of the package Ertugrul Söylemez, once an active member of >>> the community perhaps best known for netwire, passed away in 2018. [1] >>> The work required for the package thus far, and for which I've kept a >>> fork for, is to bump version bounds as GHCs progress. >>> >>> [1] https://github.com/esoeylemez/rapid/pull/2#issuecomment-427065739 >>> > > > From allbery.b at gmail.com Wed Apr 20 12:12:44 2022 From: allbery.b at gmail.com (Brandon Allbery) Date: Wed, 20 Apr 2022 08:12:44 -0400 Subject: [Haskell-cafe] Package takeover request for rapid In-Reply-To: <858d6ff1-ee5c-41e2-e695-92334e03dc80@ifi.lmu.de> References: <858d6ff1-ee5c-41e2-e695-92334e03dc80@ifi.lmu.de> Message-ID: Has anyone asked Github forhelp? I'd imagine they have some way to migrate repositories in this case by now. On Wed, Apr 20, 2022 at 8:04 AM Andreas Abel wrote: > > > By default I'd maintain it here: https://github.com/eyeinsky/rapid. > > At the least, this would need an issue tracker... > > > Are there any other options (a github organization perhaps)? > > Personally, I prefer maintaining third-party packages on github > organizations (see e.g. https://github.com/blaze-builder ). It is > easier to co-maintain and to install new maintainers. > > Github also offers transfer of repositories, but this has to be done by > the owner. Unfortunately, since Ertugrul passed away, it might be > difficult to transfer the whole repository (with issues etc.). > > Cheers, > Andreas > > On 2022-04-19 16:01, Markus Läll wrote: > > Hi Andreas, > > > > Yup, let's wait the two weeks. > > > > By default I'd maintain it here: https://github.com/eyeinsky/rapid. > > Are there any other options (a github organization perhaps)? > > > > On Tue, Apr 19, 2022 at 3:53 PM Andreas Abel wrote: > >> > >> Hello Markus, > >> > >> thanks for the initiative! > >> > >> The takeover is probably fine. It might be contested by other > >> applicants, but there aren't really any stakeholders on the source code > >> of rapid. As far as github tells me, the code was single-handedly > >> written by the now passed-away author. > >> > >> Maybe we should wait the suggested 2 weeks for any contestants before we > >> finalize the takeover. > >> > >> You will need help to get added to > >> > >> https://hackage.haskell.org/package/rapid/maintainers/ > >> > >> by one of the hackage admins (CCed). > >> > >> You would likely have to move the code to another github account, would you? > >> > >> Cheers, > >> Andreas (in my role as a hackage trustee) > >> > >> P.S.: I bumped the base-bound of rapid on hackage to ease building with > >> newer GHCs. > >> > >> On 2022-04-19 14:15, Markus Läll wrote: > >>> Hi > >>> > >>> I would like to take over https://hackage.haskell.org/package/rapid > >>> > >>> The author of the package Ertugrul Söylemez, once an active member of > >>> the community perhaps best known for netwire, passed away in 2018. [1] > >>> The work required for the package thus far, and for which I've kept a > >>> fork for, is to bump version bounds as GHCs progress. > >>> > >>> [1] https://github.com/esoeylemez/rapid/pull/2#issuecomment-427065739 > >>> > > > > > > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries -- brandon s allbery kf8nh allbery.b at gmail.com From nadine.and.henry at pobox.com Sat Apr 23 19:16:25 2022 From: nadine.and.henry at pobox.com (Henry Laxen) Date: Sat, 23 Apr 2022 12:16:25 -0700 Subject: [Haskell-cafe] Near Semi Ring problem Message-ID: <87k0bf8vau.fsf@pobox.com> Dear Group, Many years ago I read a fascinating article which I can't seem to find anymore. It was about writing down (in english) the numbers from one to a billion? and being able to retrieve the nth letter. ie: onetwothreefourfive...ninehundredninetymillion....ninetynineonebillion I remember it used near semi rings and automatic differentiation, but no matter how I use those words to search (both google and duckduck) I can't find it. Do any of you have a pointer. I believe the code was written in haskell too. Best wishes, Henry Laxen From acowley at gmail.com Sat Apr 23 19:41:34 2022 From: acowley at gmail.com (Anthony Cowley) Date: Sat, 23 Apr 2022 15:41:34 -0400 Subject: [Haskell-cafe] Near Semi Ring problem In-Reply-To: <87k0bf8vau.fsf@pobox.com> References: <87k0bf8vau.fsf@pobox.com> Message-ID: <2023AEED-B724-4580-AA1D-F867C1DE72BE@gmail.com> > On Apr 23, 2022, at 3:25 PM, Henry Laxen wrote: > >  > Dear Group, > > Many years ago I read a fascinating article which I can't seem to find > anymore. It was about writing down (in english) the numbers from one to > a billion? and being able to retrieve the nth letter. ie: > > onetwothreefourfive...ninehundredninetymillion....ninetynineonebillion > > I remember it used near semi rings and automatic differentiation, but no > matter how I use those words to search (both google and duckduck) I > can't find it. Do any of you have a pointer. I believe the code was > written in haskell too. > > Best wishes, > Henry Laxen One of my all-time favorites, too! http://conway.rutgers.edu/~ccshan/wiki/blog/posts/WordNumbers1/ Anthony -------------- next part -------------- An HTML attachment was scrubbed... URL: From leah at vuxu.org Tue Apr 26 12:01:02 2022 From: leah at vuxu.org (Leah Neukirchen) Date: Tue, 26 Apr 2022 14:01:02 +0200 Subject: [Haskell-cafe] Munich Haskell Meeting, 2022-04-28 @ 19:30 Message-ID: <87wnfcf401.fsf@vuxu.org> Dear all, This week, our monthly Munich Haskell Meeting will take place again on Thursday, April 28 at Augustiner-Gaststätte Rumpler at 19:30 CEST. For details see here: http://muenchen.haskell.bayern/dates.html If you plan to join, please add yourself to this dudle so we can reserve enough seats! It is OK to add yourself to the dudle anonymously or pseudonymously. https://dudle.inf.tu-dresden.de/haskell-munich-apr-2022/ Everybody is welcome! cu, -- Leah Neukirchen https://leahneukirchen.org/ From olf at aatal-apotheke.de Tue Apr 26 19:59:41 2022 From: olf at aatal-apotheke.de (Olaf Klinke) Date: Tue, 26 Apr 2022 21:59:41 +0200 Subject: [Haskell-cafe] Shutting down a Yesod/warp application Message-ID: Dear Cafe, this topic has been discussed [1,2] a decade ago. What is the current state of affairs in this matter? It still seems to be addressed neither in yesod nor warp [*]. We have two use cases: (1) A shutdown route that allows admins to cleanly shut down the web application. (2) We want certain exceptions to terminate the application and have the surrounding monitoring (systemd, docker, ...) re-start the application. For (2) we are safe, I think, because the worker threads are forked from the main thread [3] calling warp, so propagating the exceptions up to the top bypasses warp and yesod's very comprehensive exception handlers. But any exception thrown while answering a request (such as (1)) is caught by default. Thanks Olaf [1] https://groups.google.com/g/yesodweb/c/VoenrabRUBQ [2] https://stackoverflow.com/questions/7881327/how-do-i-implement-a-shutdown-command-in-a-wai-server [3] https://mail.haskell.org/pipermail/haskell-cafe/2022-March/135132.html [*] Warp offers setOnException and setOnExceptionResponse. But does re- throwing certain exceptions from there terminate warp? From andrei.h.popescu at gmail.com Tue Apr 26 20:35:53 2022 From: andrei.h.popescu at gmail.com (Andrei Popescu) Date: Tue, 26 Apr 2022 21:35:53 +0100 Subject: [Haskell-cafe] Position of Lecturer or Senior Lecturer in Cybersecurity at University of Sheffield Message-ID: Greetings, The Department of Computer Science at University of Sheffield has an open position of Lecturer or Senior Lecturer in Cybersecurity. Details can be found here: https://www.jobs.ac.uk/job/COY785/lecturer-senior-lecturer-in-cybersecurity Note that "formalisation and proof of system security properties" is listed as a topic of interest. Women are particularly encouraged to apply. All applicants will be given equal consideration. Best wishes, Andrei From plredmond at ucsc.edu Wed Apr 27 04:00:21 2022 From: plredmond at ucsc.edu (Patrick L Redmond) Date: Tue, 26 Apr 2022 21:00:21 -0700 Subject: [Haskell-cafe] Shutting down a Yesod/warp application In-Reply-To: References: Message-ID: Here (below) is a short program to shut down warp-3.3.15 based on a `TVar Bool` according to any policy you desire (catching a certain exception, receiving a request to a certain route, or receiving an OS signal). You need to route the TVar into places that you want to be able to initiate graceful shutdown. I believe that warp implements graceful shutdown by preventing new clients from connecting, but I haven't dug too far into its source code. In any case, the setInstallShutdownHandler documentation indicates that you should also use setGracefulShutdownTimeout to ensure the server eventually shuts down. I don't think that it's intended to throw exceptions in the setOnException handler or the setOnExceptionResponse handler. The former seems to be a hook for monitoring/logging and the latter a hook to give your users a less scary error page. --- --- --- {-# LANGUAGE OverloadedStrings #-} import qualified Control.Concurrent.Async as Async import qualified Control.Concurrent.STM as STM import qualified Network.HTTP.Types as HTTP import qualified Network.Wai as Wai import qualified Network.Wai.Handler.Warp as Warp app :: STM.TVar Bool -> Wai.Application app shutdownSignal req respond = do print ("Request from", Wai.remoteHost req) case Wai.rawPathInfo req of "/shutdown" -> do STM.atomically $ STM.writeTVar shutdownSignal True respond $ Wai.responseLBS HTTP.ok200 [] "shutting down" _ -> do respond $ Wai.responseLBS HTTP.ok200 [] "hello" -- | Spawn a thread to wait for the shutdown signal and initiate shutdown. installShutdownHandler :: STM.TVar Bool -> (IO ()) -> IO () installShutdownHandler shutdownSignal closeSocket = do _ <- Async.async $ do STM.atomically $ STM.check =<< STM.readTVar shutdownSignal closeSocket return () main :: IO () main = do shutdownSignal <- STM.newTVarIO False let settings = Warp.setPort 8080 . Warp.setInstallShutdownHandler (installShutdownHandler shutdownSignal) . Warp.setGracefulShutdownTimeout (Just 30) -- seconds $ Warp.defaultSettings print "warp is starting" Warp.runSettings settings $ app shutdownSignal print "warp is done" On Tue, Apr 26, 2022 at 1:00 PM Olaf Klinke wrote: > Dear Cafe, > > this topic has been discussed [1,2] a decade ago. What is the current > state of affairs in this matter? It still seems to be addressed neither > in yesod nor warp [*]. > We have two use cases: (1) A shutdown route that allows admins to > cleanly shut down the web application. (2) We want certain exceptions > to terminate the application and have the surrounding monitoring > (systemd, docker, ...) re-start the application. For (2) we are safe, I > think, because the worker threads are forked from the main thread [3] > calling warp, so propagating the exceptions up to the top bypasses warp > and yesod's very comprehensive exception handlers. But any exception > thrown while answering a request (such as (1)) is caught by default. > > Thanks > Olaf > > [1] https://groups.google.com/g/yesodweb/c/VoenrabRUBQ > [2] > https://stackoverflow.com/questions/7881327/how-do-i-implement-a-shutdown-command-in-a-wai-server > [3] https://mail.haskell.org/pipermail/haskell-cafe/2022-March/135132.html > [*] Warp offers setOnException and setOnExceptionResponse. But does re- > throwing certain exceptions from there terminate warp? > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From zaynah.dargaye at nomadic-labs.com Wed Apr 27 09:20:46 2022 From: zaynah.dargaye at nomadic-labs.com (Zaynah Dargaye) Date: Wed, 27 Apr 2022 11:20:46 +0200 Subject: [Haskell-cafe] Second CfP: FMBC 2022 - 4th International Workshop on Formal Methods for Blockchains Message-ID: FMBC 2022 Second Call for Papers [ Please distribute, apologies for multiple postings. ] ======================================================================== 4th International Workshop on Formal Methods for Blockchains (FMBC) - First Call https://fmbc.gitlab.io/2022 August 11, 2022, Haifa, Israel Co-located with the The Federated Logic Conference 2022 (FLoC 22 -- https://www.floc2022.org/) as a satellite workshop of the 34th International Conference on Computer-Aided Verification (CAV 2022 -- http://i-cav.org/2022/). ----------------------------------------------------------------- Important dates --------------------- Abstract submission: May 3, 2022 Full paper submission: May 10, 2022 Notification: June 15, 2022 Camera-ready: July 13, 2022 Workshop: August 11, 2022 Deadlines are Anywhere on Earth -- https://en.wikipedia.org/wiki/Anywhere_on_Earth. ---------------------- ---------------------- TOPICS OF INTEREST --------------------- Blockchains are decentralized transactional ledgers that rely on cryptographic hash functions for guaranteeing the integrity of the stored data. Participants on the network reach agreement on what valid transactions are through consensus algorithms. Blockchains may also provide support for Smart Contracts. Smart Contracts are scripts of an ad-hoc programming language that are stored in the Blockchain and that run on the network. They can interact with the ledger’s data and update its state. These scripts can express the logic of possibly complex contracts between users of the Blockchain. Thus, Smart Contracts can facilitate the economic activity of Blockchain participants. With the emergence and increasing popularity of cryptocurrencies such as Bitcoin and Ethereum, it is now of utmost importance to have strong guarantees of the behavior of Blockchain software. These guarantees can be brought by using Formal Methods. Indeed, Blockchain software encompasses many topics of computer science where using Formal Methods techniques and tools are relevant: consensus algorithms to ensure the liveness and the security of the data on the chain, programming languages specifically designed to write Smart Contracts, cryptographic protocols, such as zero-knowledge proofs, used to ensure privacy, etc. This workshop is a forum to identify theoretical and practical approaches of formal methods for Blockchain technology. Topics include, but are not limited to: * Formal models of Blockchain applications or concepts * Formal methods for consensus protocols * Formal methods for Blockchain-specific cryptographic primitives or protocols * Design and implementation of Smart Contract languages * Verification of Smart Contracts ---------------------- ---------------------- SUBMISSION --------------------- Submit original manuscripts (not published or considered elsewhere) with a page limit of 12 pages for full papers and Systematization of Knowledge (SoK) papers, 6 pages for short papers, and 2 pages for tool papers (excluding bibliography and short appendix of up to 5 additional pages). Alternatively, you may also submit an extended abstract of up to 3 pages (including a bibliography) summarizing your ongoing work in the area of formal methods and blockchain. Authors of selected extended abstracts are invited to give a short lightning talk. -------------------- -------------------- PROCEEDINGS ------------------- All submissions will be peer-reviewed by at least three members of the program committee for quality and relevance. Accepted regular papers (full and short papers) will be included in the workshop proceedings. , published as a volume of the OpenAccess Series in Informatics (OASIcs ) by Dagstuhl. ---------------------- ---------------------- INVITED SPEAKER --------------------- Massimo Bartoletti, Professor, Università degli Studi di Cagliari, Italy ---------------------- ---------------------- PROGRAM COMMITTEE --------------------- PC CO-CHAIRS * Zaynah Dargaye (Nomadic Labs, France) (zaynah.dargaye at nomadic-labs.com) * Clara Schneidewind, (MPI-SP, Germany) (clara.schneidewind at mpi-sp.org) PC MEMBERS Wolfgang Ahrendt (Chalmers University of Technology, Sweden) Leonardo Alt (Ethereum Foundation, Germany) Lacramioara Astefanoaei (Nomadic Labs, France) Roberto Blanco (MPI-SP, Germany) Joachim Breitner (Germany) Achim Brucker (University of Exeter, UK) Ethan Cecchetti (University of Maryland, USA) Manuel Chakravarty (IOHK & Tweag, Netherlands) Jing Chen (Algorand Inc, USA) Jérémie Decouchant (TU Delft, Netherlands) Antonella Del Pozzo (Université Paris-Saclay & CEA & List, France) Dana Drachsler Cohen (Technion, Israel) Cezara Dragoi (INRIA & ENS & CNRS & PSL, France) Ansgar Fehnker (Twente, Netherlands) Dominik Harz (Interlay & Imperial College London, UK) Lars Hupel (INNOQ, Germany) Igor Konnov (Informal Systems, Austria) Paul Laforgue (Nomadic Labs, France) Julian Nagele (Bank of America, USA) Russel O’Connor (Blockstream) Maria Potop-Butucaru (LIP6, France) Albert Rubio (Complutense University of Madrid, Spain) César Sanchez (IMDEA, Spain) Sun Meng (Peking University, China) Simon Thompson (IO Global, UK) Josef Widder (Informal Systems, Austria) -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.franksen at online.de Thu Apr 28 10:38:57 2022 From: ben.franksen at online.de (Ben Franksen) Date: Thu, 28 Apr 2022 12:38:57 +0200 Subject: [Haskell-cafe] Problem with ghc-9.2.2 on Windows Message-ID: Hi everyone I have a strange problem with ghc-9.2.2 on Windows. I recently updated the cabal file for darcs to allow building with ghc-9.2, which required only a few minor changes. But when I ran the tests using our github CI I noticed two regressions vs. ghc-9.0.2 on Windows. It turned out that both tests (shell scripts) try to run the darcs executable under test with a restricted PATH environment variable; the idea is to test what happens if darcs tries to run some external program which cannot be found in the PATH. The problem is that executing darcs under these circumstances fails immediately without any error message. In fact it seems to fail *before the main procedure is executed*. I tested this by printing some text to stderr in main before doing anything else and the text is not printed. The error cannot be reproduced with a simple example program, which seems to indicate that the problem may be caused by a library. But I am not aware of any way a library can influence code that is executed before main. Any kind of input on how to diagnose this problem further would be appreciated. I this were on Linux I'd use strace to find out if anything is trying to run an external program before main but this happens on Windows only and the only access I have to a Windows machine to run tests on is via the github CI. BTW, using `cabal freeze` I found these differences in library versions between the ghc-9.0 and ghc-9.2 builds. If I am not mistaken they are all "boot" libraries i.e. ones that come with ghc. ben at home[1]:.../darcs/screened>diff cabal.project.freeze-ghc-9.0 cabal.project.freeze-ghc-9.2 2c2 < constraints: any.Cabal ==3.4.1.0, --- > constraints: any.Cabal ==3.6.3.0, 25c25 < any.base ==4.15.1.0, --- > any.base ==4.16.1.0, 34c34 < any.binary ==0.8.8.0, --- > any.binary ==0.8.9.0, 37c37 < any.bytestring ==0.10.12.1, --- > any.bytestring ==0.11.3.0, 51c51 < any.containers ==0.6.4.1, --- > any.containers ==0.6.5.1, 61c61 < any.deepseq ==1.4.5.0, --- > any.deepseq ==1.4.6.1, 73c73 < any.filepath ==1.4.2.1, --- > any.filepath ==1.4.2.2, 76,78c76,78 < any.ghc-bignum ==1.1, < any.ghc-boot-th ==9.0.2, < any.ghc-prim ==0.7.0, --- > any.ghc-bignum ==1.2, > any.ghc-boot-th ==9.2.2, > any.ghc-prim ==0.8.0, 81a82 > haskeline +examples +terminfo, 113c114 < any.parsec ==3.1.14.0, --- > any.parsec ==3.1.15.0, 137c138 < any.stm ==2.5.0.0, --- > any.stm ==2.5.0.2, 148c149 < any.template-haskell ==2.17.0.0, --- > any.template-haskell ==2.18.0.0, 163c164 < any.time ==1.9.3, --- > any.time ==1.9.3 || ==1.11.1.1, Cheers Ben -- I would rather have questions that cannot be answered, than answers that cannot be questioned. -- Richard Feynman From jaro.reinders at gmail.com Thu Apr 28 10:57:04 2022 From: jaro.reinders at gmail.com (J. Reinders) Date: Thu, 28 Apr 2022 12:57:04 +0200 Subject: [Haskell-cafe] Problem with ghc-9.2.2 on Windows In-Reply-To: References: Message-ID: See https://gitlab.haskell.org/ghc/ghc/-/issues/21196 > On 28 Apr 2022, at 12:38, Ben Franksen wrote: > > Hi everyone > > I have a strange problem with ghc-9.2.2 on Windows. I recently updated the cabal file for darcs to allow building with ghc-9.2, which required only a few minor changes. But when I ran the tests using our github CI I noticed two regressions vs. ghc-9.0.2 on Windows. It turned out that both tests (shell scripts) try to run the darcs executable under test with a restricted PATH environment variable; the idea is to test what happens if darcs tries to run some external program which cannot be found in the PATH. > > The problem is that executing darcs under these circumstances fails immediately without any error message. In fact it seems to fail *before the main procedure is executed*. I tested this by printing some text to stderr in main before doing anything else and the text is not printed. The error cannot be reproduced with a simple example program, which seems to indicate that the problem may be caused by a library. But I am not aware of any way a library can influence code that is executed before main. > > Any kind of input on how to diagnose this problem further would be appreciated. I this were on Linux I'd use strace to find out if anything is trying to run an external program before main but this happens on Windows only and the only access I have to a Windows machine to run tests on is via the github CI. > > BTW, using `cabal freeze` I found these differences in library versions between the ghc-9.0 and ghc-9.2 builds. If I am not mistaken they are all "boot" libraries i.e. ones that come with ghc. > > ben at home[1]:.../darcs/screened>diff cabal.project.freeze-ghc-9.0 cabal.project.freeze-ghc-9.2 > 2c2 > < constraints: any.Cabal ==3.4.1.0, > --- > > constraints: any.Cabal ==3.6.3.0, > 25c25 > < any.base ==4.15.1.0, > --- > > any.base ==4.16.1.0, > 34c34 > < any.binary ==0.8.8.0, > --- > > any.binary ==0.8.9.0, > 37c37 > < any.bytestring ==0.10.12.1, > --- > > any.bytestring ==0.11.3.0, > 51c51 > < any.containers ==0.6.4.1, > --- > > any.containers ==0.6.5.1, > 61c61 > < any.deepseq ==1.4.5.0, > --- > > any.deepseq ==1.4.6.1, > 73c73 > < any.filepath ==1.4.2.1, > --- > > any.filepath ==1.4.2.2, > 76,78c76,78 > < any.ghc-bignum ==1.1, > < any.ghc-boot-th ==9.0.2, > < any.ghc-prim ==0.7.0, > --- > > any.ghc-bignum ==1.2, > > any.ghc-boot-th ==9.2.2, > > any.ghc-prim ==0.8.0, > 81a82 > > haskeline +examples +terminfo, > 113c114 > < any.parsec ==3.1.14.0, > --- > > any.parsec ==3.1.15.0, > 137c138 > < any.stm ==2.5.0.0, > --- > > any.stm ==2.5.0.2, > 148c149 > < any.template-haskell ==2.17.0.0, > --- > > any.template-haskell ==2.18.0.0, > 163c164 > < any.time ==1.9.3, > --- > > any.time ==1.9.3 || ==1.11.1.1, > > Cheers > Ben > -- > I would rather have questions that cannot be answered, than answers that > cannot be questioned. -- Richard Feynman > > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. From ben.franksen at online.de Thu Apr 28 11:24:18 2022 From: ben.franksen at online.de (Ben Franksen) Date: Thu, 28 Apr 2022 13:24:18 +0200 Subject: [Haskell-cafe] Problem with ghc-9.2.2 on Windows In-Reply-To: References: Message-ID: Am 28.04.22 um 12:57 schrieb J. Reinders: > See https://gitlab.haskell.org/ghc/ghc/-/issues/21196 Thanks a lot! Indeed, looks as if it's the same problem. I'll wait for 9.2.3 then. Ben -- I would rather have questions that cannot be answered, than answers that cannot be questioned. -- Richard Feynman From andreeac at comp.nus.edu.sg Fri Apr 29 03:16:30 2022 From: andreeac at comp.nus.edu.sg (Andreea Costea) Date: Fri, 29 Apr 2022 11:16:30 +0800 Subject: [Haskell-cafe] SPLASH 2022 Final Call for Workshop Proposals Message-ID: ======================================================================== SPLASH 2022 Call for Workshops The ACM Conference on Systems, Programming, Languages, and Applications: Software for Humanity December 5-10, 2022, Auckland, New Zealand https://2022.splashcon.org/track/splash-2022-Workshops ======================================================================== We encourage proposals for workshops on any topic relevant to SPLASH. If there is a topic that you feel passionate about, and want to connect with others who have similar interests, submit a workshop proposal! We more than welcome new, and unconventional ideas for workshop formats. The following suggestions are a starting point: - Conference-style workshops allow participants to present their work to other domain experts. The smaller and more focused setting of a workshop allows for Q&A sessions and facilitates discussions. Presentations of work-in-progress are welcome. - Retreats act as a platform for experts to gather to tackle issues of a predetermined research agenda. Retreats are highly interactive and goal-oriented, allowing participants to address open challenges, explore new and uncharted ideas. - Agenda-setting workshops provide a forum for experts to determine a research agenda for a sub-field. - Other common activities at workshops include poster sessions, hands-on practical work, and focus groups. Workshops that include the presentation of research papers and that implement a SIGPLAN-approved selection process may archive proceedings in the ACM Digital Library. The workshop chairs will provide advice on achieving this for those interested. Workshop applications will be considered until **May 01, 2022**, or until all slots are allocated. We will also entertain requests for workshops to be held in remote or hybrid modes. ## Workshop Proposal Submission Visit the submission link for the workshop proposal form and for more information on requirements and the evaluation process. To submit a workshop proposal, you will need to login to http://conf.research.org. ## Important Deadlines - The deadline for proposal submission for all workshops is **May 01, 2022** - The deadline for paper/abstract submission for all workshops is **September 01, 2022** - The early registration deadline for SPLASH is **TBD**. Before the SPLASH early registration deadline, all workshops must a) send out accept/reject notifications, and b) publish a draft schedule on the SPLASH website. For workshops with proceedings published in the ACM Digital Library, **TBD** is the camera-ready deadline. Therefore, you should plan to notify authors several days before this date, so that they have time for revisions. **TBD** dates will be announced as soon as the SPLASH dates they are dependent on are decided. ## Questions Please [email the workshop co-chairs](mailto:workshops at splashcon.org) with any questions. ## Submission Link https://bit.ly/splash2022w ## Organizing Committee - Mehdi Bagherzadeh, Oakland University, USA - Raffi Khatchadourian, CUNY Hunter College, USA