From post at volker-wysk.de Mon Apr 1 11:20:37 2024 From: post at volker-wysk.de (Volker Wysk) Date: Mon, 01 Apr 2024 13:20:37 +0200 Subject: [Haskell-cafe] Hackage: "Build: PlanningFailed" In-Reply-To: <506BB5E6-F1F5-4045-BCAA-6F8137949CAF@gmail.com> References: <60d104a71b747f99abea9f101ea100853913167c.camel@volker-wysk.de> <6364b4595482525289613c54ba30e2df6adb0806.camel@volker-wysk.de> <041cc11e5a27b6a53d6e89d2cfff6a3043da7fb5.camel@volker-wysk.de> <9c519a6a0eed414c27b5cd64f511d769c32e5f22.camel@volker-wysk.de> <506BB5E6-F1F5-4045-BCAA-6F8137949CAF@gmail.com> Message-ID: Am Sonntag, dem 31.03.2024 um 18:22 +0100 schrieb Andrew Lelechenko: > If triggering rebuild does not work immediately, remove documentation > first and trigger rebuild afterwards.  > > There are 4 build reports > now: https://hackage.haskell.org/package/hsshellscript-3.6.2/reports/4, > but the latest one fails because, as it seems, your package does not > actually support GHC 9.6 and newer dependencies. Yes, that's what it looks like. It's good that you noticed it. I'm a Linux user (with Ubuntu 22.04 LTS). My GHC (8.8.4) comes with the haskell-platform metapackage. GHC 9.8.2 should be included in Ubuntu 24.04 LTS. I see no easy way to get a running GHC 9.6. now, so I can fix it. According to https://wiki.haskell.org/Base_package , my GHC version, 8.8.4, should have been released between Jul 2019 and Mar 2020. That's way before my Ubuntu 22.04 distribution. I don't get it, why such an old version is being shipped. The ghc version in the newest Ubuntu (23.10) is old too... So for now, I'll change the upper bound of the base package version back to 4.14 and support only GHC 8.8. Until I have a running Haskell platform with the newest GHC version again. Looks like I have to install it manually, not via apt. Cheers, Volker From iustin at k1024.org Mon Apr 1 11:29:26 2024 From: iustin at k1024.org (Iustin Pop) Date: Mon, 1 Apr 2024 13:29:26 +0200 Subject: [Haskell-cafe] Hackage: "Build: PlanningFailed" In-Reply-To: References: <60d104a71b747f99abea9f101ea100853913167c.camel@volker-wysk.de> <6364b4595482525289613c54ba30e2df6adb0806.camel@volker-wysk.de> <041cc11e5a27b6a53d6e89d2cfff6a3043da7fb5.camel@volker-wysk.de> <9c519a6a0eed414c27b5cd64f511d769c32e5f22.camel@volker-wysk.de> <506BB5E6-F1F5-4045-BCAA-6F8137949CAF@gmail.com> Message-ID: On 2024-04-01 13:20:37, Volker Wysk wrote: > Am Sonntag, dem 31.03.2024 um 18:22 +0100 schrieb Andrew Lelechenko: > > If triggering rebuild does not work immediately, remove documentation > > first and trigger rebuild afterwards.  > > > > There are 4 build reports > > now: https://hackage.haskell.org/package/hsshellscript-3.6.2/reports/4, > > but the latest one fails because, as it seems, your package does not > > actually support GHC 9.6 and newer dependencies. > > Yes, that's what it looks like. It's good that you noticed it. > > I'm a Linux user (with Ubuntu 22.04 LTS). My GHC (8.8.4) comes with the > haskell-platform metapackage. GHC 9.8.2 should be included in Ubuntu 24.04 > LTS. I see no easy way to get a running GHC 9.6. now, so I can fix it. > > According to https://wiki.haskell.org/Base_package , my GHC version, 8.8.4, > should have been released between Jul 2019 and Mar 2020. That's way before > my Ubuntu 22.04 distribution. I don't get it, why such an old version is > being shipped. The ghc version in the newest Ubuntu (23.10) is old too... Because the way entire toolchains and the associated libraries are built and transitioned, you can't simply upgrade the compiler. A GHC or Perl of Python transition in Debian (and thus Ubuntu) takes 1-2 months to fully roll out, and more so probably for compiled things such as Haskell. Plus, the entire distribution is stabilised before the final released. So you should count at least 6 months, if not a year, before the distribution release date. Debian's Haskell group could always use more hands as well ;-) Just use ghcup or a more recent distribution within a VM to debug and test. regards, iustin From lemming at henning-thielemann.de Mon Apr 1 11:38:01 2024 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Mon, 1 Apr 2024 13:38:01 +0200 (CEST) Subject: [Haskell-cafe] Hackage: "Build: PlanningFailed" In-Reply-To: References: <60d104a71b747f99abea9f101ea100853913167c.camel@volker-wysk.de> <6364b4595482525289613c54ba30e2df6adb0806.camel@volker-wysk.de> <041cc11e5a27b6a53d6e89d2cfff6a3043da7fb5.camel@volker-wysk.de> <9c519a6a0eed414c27b5cd64f511d769c32e5f22.camel@volker-wysk.de> <506BB5E6-F1F5-4045-BCAA-6F8137949CAF@gmail.com> Message-ID: On Mon, 1 Apr 2024, Iustin Pop wrote: > Because the way entire toolchains and the associated libraries are built > and transitioned, you can't simply upgrade the compiler. A GHC or Perl > of Python transition in Debian (and thus Ubuntu) takes 1-2 months to > fully roll out, and more so probably for compiled things such as > Haskell. Plus, the entire distribution is stabilised before the final > released. > > So you should count at least 6 months, if not a year, before the > distribution release date. Debian's Haskell group could always use more > hands as well ;-) > > Just use ghcup or a more recent distribution within a VM to debug and > test. One can use Nix to install newer versions even under Ubuntu. I actually install the Linux binary tarballs and compress them in a squasfs, because every GHC installation consumes more than a gigaton of harddisk space. From allbery.b at gmail.com Mon Apr 1 15:41:30 2024 From: allbery.b at gmail.com (Brandon Allbery) Date: Mon, 1 Apr 2024 11:41:30 -0400 Subject: [Haskell-cafe] Hackage: "Build: PlanningFailed" In-Reply-To: References: <60d104a71b747f99abea9f101ea100853913167c.camel@volker-wysk.de> <6364b4595482525289613c54ba30e2df6adb0806.camel@volker-wysk.de> <041cc11e5a27b6a53d6e89d2cfff6a3043da7fb5.camel@volker-wysk.de> <9c519a6a0eed414c27b5cd64f511d769c32e5f22.camel@volker-wysk.de> <506BB5E6-F1F5-4045-BCAA-6F8137949CAF@gmail.com> Message-ID: Debian pretty much didn't have a Haskell maintainers group for much of that time period. There's a new group now, but it's taking time for them to modernize everything. On Mon, Apr 1, 2024 at 7:29 AM Iustin Pop wrote: > On 2024-04-01 13:20:37, Volker Wysk wrote: > > Am Sonntag, dem 31.03.2024 um 18:22 +0100 schrieb Andrew Lelechenko: > > > If triggering rebuild does not work immediately, remove documentation > > > first and trigger rebuild afterwards. > > > > > > There are 4 build reports > > > now: https://hackage.haskell.org/package/hsshellscript-3.6.2/reports/4 > , > > > but the latest one fails because, as it seems, your package does not > > > actually support GHC 9.6 and newer dependencies. > > > > Yes, that's what it looks like. It's good that you noticed it. > > > > I'm a Linux user (with Ubuntu 22.04 LTS). My GHC (8.8.4) comes with the > > haskell-platform metapackage. GHC 9.8.2 should be included in Ubuntu > 24.04 > > LTS. I see no easy way to get a running GHC 9.6. now, so I can fix it. > > > > According to https://wiki.haskell.org/Base_package , my GHC version, > 8.8.4, > > should have been released between Jul 2019 and Mar 2020. That's way > before > > my Ubuntu 22.04 distribution. I don't get it, why such an old version is > > being shipped. The ghc version in the newest Ubuntu (23.10) is old too... > > Because the way entire toolchains and the associated libraries are built > and transitioned, you can't simply upgrade the compiler. A GHC or Perl > of Python transition in Debian (and thus Ubuntu) takes 1-2 months to > fully roll out, and more so probably for compiled things such as > Haskell. Plus, the entire distribution is stabilised before the final > released. > > So you should count at least 6 months, if not a year, before the > distribution release date. Debian's Haskell group could always use more > hands as well ;-) > > Just use ghcup or a more recent distribution within a VM to debug and > test. > > regards, > iustin > _______________________________________________ > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.lelechenko at gmail.com Mon Apr 1 21:20:23 2024 From: andrew.lelechenko at gmail.com (Andrew Lelechenko) Date: Mon, 1 Apr 2024 22:20:23 +0100 Subject: [Haskell-cafe] Hackage: "Build: PlanningFailed" In-Reply-To: References: <60d104a71b747f99abea9f101ea100853913167c.camel@volker-wysk.de> <6364b4595482525289613c54ba30e2df6adb0806.camel@volker-wysk.de> <041cc11e5a27b6a53d6e89d2cfff6a3043da7fb5.camel@volker-wysk.de> <9c519a6a0eed414c27b5cd64f511d769c32e5f22.camel@volker-wysk.de> <506BB5E6-F1F5-4045-BCAA-6F8137949CAF@gmail.com> Message-ID: <149A7B8A-AD07-42FC-8A13-967C44FDA581@gmail.com> Just use ghcup (https://www.haskell.org/ghcup/install/)? Best regards, Andrew > On 1 Apr 2024, at 12:20, Volker Wysk wrote: > > Am Sonntag, dem 31.03.2024 um 18:22 +0100 schrieb Andrew Lelechenko: >> If triggering rebuild does not work immediately, remove documentation >> first and trigger rebuild afterwards. >> >> There are 4 build reports >> now: https://hackage.haskell.org/package/hsshellscript-3.6.2/reports/4, >> but the latest one fails because, as it seems, your package does not >> actually support GHC 9.6 and newer dependencies. > > Yes, that's what it looks like. It's good that you noticed it. > > I'm a Linux user (with Ubuntu 22.04 LTS). My GHC (8.8.4) comes with the > haskell-platform metapackage. GHC 9.8.2 should be included in Ubuntu 24.04 > LTS. I see no easy way to get a running GHC 9.6. now, so I can fix it. > > According to https://wiki.haskell.org/Base_package , my GHC version, 8.8.4, > should have been released between Jul 2019 and Mar 2020. That's way before > my Ubuntu 22.04 distribution. I don't get it, why such an old version is > being shipped. The ghc version in the newest Ubuntu (23.10) is old too... > > So for now, I'll change the upper bound of the base package version back to > 4.14 and support only GHC 8.8. Until I have a running Haskell platform with > the newest GHC version again. Looks like I have to install it manually, not > via apt. > > Cheers, > Volker > _______________________________________________ > 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 post at volker-wysk.de Tue Apr 2 11:22:42 2024 From: post at volker-wysk.de (Volker Wysk) Date: Tue, 02 Apr 2024 13:22:42 +0200 Subject: [Haskell-cafe] Cabal: Can only one processor core be used? Message-ID: <0327e0d4b29c24e681cc66962495380554abe0d6.camel@volker-wysk.de> Hi I've searched the web and the cabal user guide on how to use more processor cores for compilation via cabal. I couldn't find anything. It looks like only one processor core can be used with cabal, even though (I've read on the web) GHC supports parallel compilation. Cabal compilation times can be a pain. It can't be that you can use only one processor core with cabal, can it ..? Cheers, Volker From vagarenko at gmail.com Tue Apr 2 11:37:38 2024 From: vagarenko at gmail.com (Alexey Vagarenko) Date: Tue, 2 Apr 2024 16:37:38 +0500 Subject: [Haskell-cafe] Cabal: Can only one processor core be used? In-Reply-To: <0327e0d4b29c24e681cc66962495380554abe0d6.camel@volker-wysk.de> References: <0327e0d4b29c24e681cc66962495380554abe0d6.camel@volker-wysk.de> Message-ID: Hi, There is -j flag for this: https://cabal.readthedocs.io/en/3.4/cabal-project.html#cfg-field-jobs On Tue, Apr 2, 2024 at 4:23 PM Volker Wysk wrote: > Hi > > I've searched the web and the cabal user guide on how to use more processor > cores for compilation via cabal. I couldn't find anything. > > It looks like only one processor core can be used with cabal, even though > (I've read on the web) GHC supports parallel compilation. > > Cabal compilation times can be a pain. It can't be that you can use only > one > processor core with cabal, can it ..? > > Cheers, > Volker > _______________________________________________ > 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 lemming at henning-thielemann.de Tue Apr 2 11:38:41 2024 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Tue, 2 Apr 2024 13:38:41 +0200 (CEST) Subject: [Haskell-cafe] Cabal: Can only one processor core be used? In-Reply-To: <0327e0d4b29c24e681cc66962495380554abe0d6.camel@volker-wysk.de> References: <0327e0d4b29c24e681cc66962495380554abe0d6.camel@volker-wysk.de> Message-ID: <4742bf4f-8254-6151-3754-7e9d6928b812@henning-thielemann.de> On Tue, 2 Apr 2024, Volker Wysk wrote: > I've searched the web and the cabal user guide on how to use more processor > cores for compilation via cabal. I couldn't find anything. $ cabal install -j3 or $ fgrep jobs ~/.cabal/config jobs: 3 > Cabal compilation times can be a pain. It can't be that you can use only > one processor core with cabal, can it ..? There are two places where you can increase the use of multiple cores. The one above controls the number of packages to be compiled in parallel, whereas $ cabal install --ghc-option=-j3 means that each instance of GHC compiles up to three modules in parallel. As far as I know it is currently not possible to interleave compilation of modules and packages. I.e. optimally we would only need one 'jobs' option and then Cabal and GHC manage to fill the working queue with any module from any package. This would certainly require to run GHC in a server mode. However, without a fast storage for temporary files you will hardly see an actual speedup. I use to mount a ram disk with tmpfs at /ram and then compile with $ cabal install -j3 --ghc-option=-j3 --builddir=/ram/cabal From coot at coot.me Tue Apr 2 11:47:03 2024 From: coot at coot.me (coot at coot.me) Date: Tue, 02 Apr 2024 11:47:03 +0000 Subject: [Haskell-cafe] Cabal: Can only one processor core be used? In-Reply-To: References: <0327e0d4b29c24e681cc66962495380554abe0d6.camel@volker-wysk.de> Message-ID: Let's also mention that there's work to have a single semaphore which governs the concurrency in a better way which allows the tooling to dynamically decide how many cores to use for compiling a package when multiple of them are being compiled. Regards, Marcin Sent with Proton Mail secure email. On Tuesday, 2 April 2024 at 13:37, Alexey Vagarenko wrote: > Hi, > > There is -j flag for this: https://cabal.readthedocs.io/en/3.4/cabal-project.html#cfg-field-jobs > > On Tue, Apr 2, 2024 at 4:23 PM Volker Wysk wrote: > > > Hi > > > > I've searched the web and the cabal user guide on how to use more processor > > cores for compilation via cabal. I couldn't find anything. > > > > It looks like only one processor core can be used with cabal, even though > > (I've read on the web) GHC supports parallel compilation. > > > > Cabal compilation times can be a pain. It can't be that you can use only one > > processor core with cabal, can it ..? > > > > Cheers, > > Volker > > _______________________________________________ > > 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 -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 509 bytes Desc: OpenPGP digital signature URL: From post at volker-wysk.de Tue Apr 2 11:49:35 2024 From: post at volker-wysk.de (Volker Wysk) Date: Tue, 02 Apr 2024 13:49:35 +0200 Subject: [Haskell-cafe] Cabal: Can only one processor core be used? In-Reply-To: References: <0327e0d4b29c24e681cc66962495380554abe0d6.camel@volker-wysk.de> Message-ID: <3f831399ce3f8405670c27de41d07c1b1cffb395.camel@volker-wysk.de> Am Dienstag, dem 02.04.2024 um 16:37 +0500 schrieb Alexey Vagarenko: > Hi, > > There is -j flag for this: > https://cabal.readthedocs.io/en/3.4/cabal-project.html#cfg-field-jobs Okay, great. But only whole packages will be compiled in parallel, as Henning has pointed out. Cheers, Volker > On Tue, Apr 2, 2024 at 4:23 PM Volker Wysk wrote: > > Hi > > > > I've searched the web and the cabal user guide on how to use more > > processor > > cores for compilation via cabal. I couldn't find anything. > > > > It looks like only one processor core can be used with cabal, even > > though > > (I've read on the web) GHC supports parallel compilation. > > > > Cabal compilation times can be a pain. It can't be that you can use only > > one > > processor core with cabal, can it ..? > > > > Cheers, > > Volker > > _______________________________________________ > > 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 post at volker-wysk.de Tue Apr 2 11:55:11 2024 From: post at volker-wysk.de (Volker Wysk) Date: Tue, 02 Apr 2024 13:55:11 +0200 Subject: [Haskell-cafe] Cabal: Can only one processor core be used? In-Reply-To: <4742bf4f-8254-6151-3754-7e9d6928b812@henning-thielemann.de> References: <0327e0d4b29c24e681cc66962495380554abe0d6.camel@volker-wysk.de> <4742bf4f-8254-6151-3754-7e9d6928b812@henning-thielemann.de> Message-ID: <2b5722e84ab6a0b244527b89bda3609a4fe03ed8.camel@volker-wysk.de> Am Dienstag, dem 02.04.2024 um 13:38 +0200 schrieb Henning Thielemann: > On Tue, 2 Apr 2024, Volker Wysk wrote: > > > I've searched the web and the cabal user guide on how to use more processor > > cores for compilation via cabal. I couldn't find anything. > > $ cabal install -j3 > > or > > $ fgrep jobs ~/.cabal/config > jobs: 3 > > > > Cabal compilation times can be a pain. It can't be that you can use only > > one processor core with cabal, can it ..? > > There are two places where you can increase the use of multiple cores. The > one above controls the number of packages to be compiled in parallel, > whereas > > $ cabal install --ghc-option=-j3 > > means that each instance of GHC compiles up to three modules in parallel. This sounds better than compiling only whole packages in parallel. > As far as I know it is currently not possible to interleave compilation of > modules and packages. I.e. optimally we would only need one 'jobs' option > and then Cabal and GHC manage to fill the working queue with any module > from any package. This would certainly require to run GHC in a server > mode. > > > However, without a fast storage for temporary files you will hardly see an > actual speedup. I use to mount a ram disk with tmpfs at /ram and then > compile with > > $ cabal install -j3 --ghc-option=-j3 --builddir=/ram/cabal That's important. And so you're saying that an SSD isn't fast enough. So I'll probably set up a RAM disk as well. Thanks Volker From bryan at haskell.foundation Tue Apr 2 12:06:51 2024 From: bryan at haskell.foundation (Bryan Richter) Date: Tue, 2 Apr 2024 15:06:51 +0300 Subject: [Haskell-cafe] Cabal: Can only one processor core be used? In-Reply-To: <3f831399ce3f8405670c27de41d07c1b1cffb395.camel@volker-wysk.de> References: <0327e0d4b29c24e681cc66962495380554abe0d6.camel@volker-wysk.de> <3f831399ce3f8405670c27de41d07c1b1cffb395.camel@volker-wysk.de> Message-ID: BTW the "semaphore" solution mentioned was introduced in this proposal: https://github.com/ghc-proposals/ghc-proposals/pull/540 Looks like it may be present in the latest Cabal (3.10) and latest GHC (9.8)? I'm curious to know if anyone's using it yet. :) On Tue, 2 Apr 2024 at 14:50, Volker Wysk wrote: > > Am Dienstag, dem 02.04.2024 um 16:37 +0500 schrieb Alexey Vagarenko: > > Hi, > > > > There is -j flag for this: > > https://cabal.readthedocs.io/en/3.4/cabal-project.html#cfg-field-jobs > > Okay, great. But only whole packages will be compiled in parallel, as > Henning has pointed out. > > Cheers, > Volker > > > On Tue, Apr 2, 2024 at 4:23 PM Volker Wysk wrote: > > > Hi > > > > > > I've searched the web and the cabal user guide on how to use more > > > processor > > > cores for compilation via cabal. I couldn't find anything. > > > > > > It looks like only one processor core can be used with cabal, even > > > though > > > (I've read on the web) GHC supports parallel compilation. > > > > > > Cabal compilation times can be a pain. It can't be that you can use only > > > one > > > processor core with cabal, can it ..? > > > > > > Cheers, > > > Volker > > > _______________________________________________ > > > 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 allbery.b at gmail.com Tue Apr 2 15:18:45 2024 From: allbery.b at gmail.com (Brandon Allbery) Date: Tue, 2 Apr 2024 11:18:45 -0400 Subject: [Haskell-cafe] Cabal: Can only one processor core be used? In-Reply-To: References: <0327e0d4b29c24e681cc66962495380554abe0d6.camel@volker-wysk.de> <3f831399ce3f8405670c27de41d07c1b1cffb395.camel@volker-wysk.de> Message-ID: It's only in HEAD at present and will be in 3.12. On Tue, Apr 2, 2024 at 8:07 AM Bryan Richter via Haskell-Cafe < haskell-cafe at haskell.org> wrote: > BTW the "semaphore" solution mentioned was introduced in this > proposal: https://github.com/ghc-proposals/ghc-proposals/pull/540 > > Looks like it may be present in the latest Cabal (3.10) and latest GHC > (9.8)? I'm curious to know if anyone's using it yet. :) > > > On Tue, 2 Apr 2024 at 14:50, Volker Wysk wrote: > > > > Am Dienstag, dem 02.04.2024 um 16:37 +0500 schrieb Alexey Vagarenko: > > > Hi, > > > > > > There is -j flag for this: > > > https://cabal.readthedocs.io/en/3.4/cabal-project.html#cfg-field-jobs > > > > Okay, great. But only whole packages will be compiled in parallel, as > > Henning has pointed out. > > > > Cheers, > > Volker > > > > > On Tue, Apr 2, 2024 at 4:23 PM Volker Wysk > wrote: > > > > Hi > > > > > > > > I've searched the web and the cabal user guide on how to use more > > > > processor > > > > cores for compilation via cabal. I couldn't find anything. > > > > > > > > It looks like only one processor core can be used with cabal, even > > > > though > > > > (I've read on the web) GHC supports parallel compilation. > > > > > > > > Cabal compilation times can be a pain. It can't be that you can use > only > > > > one > > > > processor core with cabal, can it ..? > > > > > > > > Cheers, > > > > Volker > > > > _______________________________________________ > > > > 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. > _______________________________________________ > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.lelechenko at gmail.com Tue Apr 2 21:32:35 2024 From: andrew.lelechenko at gmail.com (Andrew Lelechenko) Date: Tue, 2 Apr 2024 22:32:35 +0100 Subject: [Haskell-cafe] Cabal: Can only one processor core be used? In-Reply-To: References: <0327e0d4b29c24e681cc66962495380554abe0d6.camel@volker-wysk.de> <3f831399ce3f8405670c27de41d07c1b1cffb395.camel@volker-wysk.de> Message-ID: I’ve been using semaphore concurrency builds since GHC 9.8 was released. Works like a charm, very nice, but yes, one has to build cabal-install HEAD or wait until cabal-3.12 is out (which is soon AFAIU). Best regards, Andrew > On 2 Apr 2024, at 16:18, Brandon Allbery wrote: > > It's only in HEAD at present and will be in 3.12. > > On Tue, Apr 2, 2024 at 8:07 AM Bryan Richter via Haskell-Cafe wrote: > BTW the "semaphore" solution mentioned was introduced in this > proposal: https://github.com/ghc-proposals/ghc-proposals/pull/540 > > Looks like it may be present in the latest Cabal (3.10) and latest GHC > (9.8)? I'm curious to know if anyone's using it yet. :) > > > On Tue, 2 Apr 2024 at 14:50, Volker Wysk wrote: > > > > Am Dienstag, dem 02.04.2024 um 16:37 +0500 schrieb Alexey Vagarenko: > > > Hi, > > > > > > There is -j flag for this: > > > https://cabal.readthedocs.io/en/3.4/cabal-project.html#cfg-field-jobs > > > > Okay, great. But only whole packages will be compiled in parallel, as > > Henning has pointed out. > > > > Cheers, > > Volker > > > > > On Tue, Apr 2, 2024 at 4:23 PM Volker Wysk wrote: > > > > Hi > > > > > > > > I've searched the web and the cabal user guide on how to use more > > > > processor > > > > cores for compilation via cabal. I couldn't find anything. > > > > > > > > It looks like only one processor core can be used with cabal, even > > > > though > > > > (I've read on the web) GHC supports parallel compilation. > > > > > > > > Cabal compilation times can be a pain. It can't be that you can use only > > > > one > > > > processor core with cabal, can it ..? > > > > > > > > Cheers, > > > > Volker > > > > _______________________________________________ > > > > 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. > _______________________________________________ > 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 > _______________________________________________ > 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 Tue Apr 2 21:44:42 2024 From: allbery.b at gmail.com (Brandon Allbery) Date: Tue, 2 Apr 2024 17:44:42 -0400 Subject: [Haskell-cafe] Cabal: Can only one processor core be used? In-Reply-To: References: <0327e0d4b29c24e681cc66962495380554abe0d6.camel@volker-wysk.de> <3f831399ce3f8405670c27de41d07c1b1cffb395.camel@volker-wysk.de> Message-ID: You don't have to build it yourself, there's a `cabal-head` release on github where you can download it or use: ghcup install cabal --force -u https://github.com/haskell/cabal/releases/download/cabal-head/cabal-head-Linux-x86_64.tar.gz head On Tue, Apr 2, 2024 at 5:33 PM Andrew Lelechenko < andrew.lelechenko at gmail.com> wrote: > I’ve been using semaphore concurrency builds since GHC 9.8 was released. > Works like a charm, very nice, but yes, one has to build cabal-install HEAD > or wait until cabal-3.12 is out (which is soon AFAIU). > > Best regards, > Andrew > > > > On 2 Apr 2024, at 16:18, Brandon Allbery wrote: > > > > It's only in HEAD at present and will be in 3.12. > > > > On Tue, Apr 2, 2024 at 8:07 AM Bryan Richter via Haskell-Cafe < > haskell-cafe at haskell.org> wrote: > > BTW the "semaphore" solution mentioned was introduced in this > > proposal: https://github.com/ghc-proposals/ghc-proposals/pull/540 > > > > Looks like it may be present in the latest Cabal (3.10) and latest GHC > > (9.8)? I'm curious to know if anyone's using it yet. :) > > > > > > On Tue, 2 Apr 2024 at 14:50, Volker Wysk wrote: > > > > > > Am Dienstag, dem 02.04.2024 um 16:37 +0500 schrieb Alexey Vagarenko: > > > > Hi, > > > > > > > > There is -j flag for this: > > > > > https://cabal.readthedocs.io/en/3.4/cabal-project.html#cfg-field-jobs > > > > > > Okay, great. But only whole packages will be compiled in parallel, as > > > Henning has pointed out. > > > > > > Cheers, > > > Volker > > > > > > > On Tue, Apr 2, 2024 at 4:23 PM Volker Wysk > wrote: > > > > > Hi > > > > > > > > > > I've searched the web and the cabal user guide on how to use more > > > > > processor > > > > > cores for compilation via cabal. I couldn't find anything. > > > > > > > > > > It looks like only one processor core can be used with cabal, even > > > > > though > > > > > (I've read on the web) GHC supports parallel compilation. > > > > > > > > > > Cabal compilation times can be a pain. It can't be that you can > use only > > > > > one > > > > > processor core with cabal, can it ..? > > > > > > > > > > Cheers, > > > > > Volker > > > > > _______________________________________________ > > > > > 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. > > _______________________________________________ > > 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 > > _______________________________________________ > > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From post at volker-wysk.de Wed Apr 3 05:41:04 2024 From: post at volker-wysk.de (Volker Wysk) Date: Wed, 03 Apr 2024 07:41:04 +0200 Subject: [Haskell-cafe] Hackage: "Build: PlanningFailed" In-Reply-To: References: <60d104a71b747f99abea9f101ea100853913167c.camel@volker-wysk.de> <6364b4595482525289613c54ba30e2df6adb0806.camel@volker-wysk.de> <041cc11e5a27b6a53d6e89d2cfff6a3043da7fb5.camel@volker-wysk.de> <9c519a6a0eed414c27b5cd64f511d769c32e5f22.camel@volker-wysk.de> <506BB5E6-F1F5-4045-BCAA-6F8137949CAF@gmail.com> Message-ID: <0ec260fe84ab612a27b18c4c96d3795556ff353b.camel@volker-wysk.de> Am Montag, dem 01.04.2024 um 13:29 +0200 schrieb Iustin Pop: > On 2024-04-01 13:20:37, Volker Wysk wrote: > > Am Sonntag, dem 31.03.2024 um 18:22 +0100 schrieb Andrew Lelechenko: > > > If triggering rebuild does not work immediately, remove documentation > > > first and trigger rebuild afterwards.  > > > > > > There are 4 build reports > > > now: https://hackage.haskell.org/package/hsshellscript-3.6.2/reports/4, > > > but the latest one fails because, as it seems, your package does not > > > actually support GHC 9.6 and newer dependencies. > > > > Yes, that's what it looks like. It's good that you noticed it. > > > > I'm a Linux user (with Ubuntu 22.04 LTS). My GHC (8.8.4) comes with the > > haskell-platform metapackage. GHC 9.8.2 should be included in Ubuntu 24.04 > > LTS. I see no easy way to get a running GHC 9.6. now, so I can fix it. > > > > According to https://wiki.haskell.org/Base_package , my GHC version, 8.8.4, > > should have been released between Jul 2019 and Mar 2020. That's way before > > my Ubuntu 22.04 distribution. I don't get it, why such an old version is > > being shipped. The ghc version in the newest Ubuntu (23.10) is old too... > > Because the way entire toolchains and the associated libraries are built > and transitioned, you can't simply upgrade the compiler. A GHC or Perl > of Python transition in Debian (and thus Ubuntu) takes 1-2 months to > fully roll out, and more so probably for compiled things such as > Haskell. Plus, the entire distribution is stabilised before the final > released. > > So you should count at least 6 months, if not a year, before the > distribution release date. Debian's Haskell group could always use more > hands as well ;-) > > Just use ghcup or a more recent distribution within a VM to debug and > test. I've installed it via ghcup. That was easy! Thanks for the tip. I've uploaded hsshellscript to Hackage now. It seems like all works, but there is no build report. Volker From post at volker-wysk.de Wed Apr 3 05:43:24 2024 From: post at volker-wysk.de (Volker Wysk) Date: Wed, 03 Apr 2024 07:43:24 +0200 Subject: [Haskell-cafe] Hackage: "Build: PlanningFailed" In-Reply-To: References: <60d104a71b747f99abea9f101ea100853913167c.camel@volker-wysk.de> <6364b4595482525289613c54ba30e2df6adb0806.camel@volker-wysk.de> <041cc11e5a27b6a53d6e89d2cfff6a3043da7fb5.camel@volker-wysk.de> <9c519a6a0eed414c27b5cd64f511d769c32e5f22.camel@volker-wysk.de> <506BB5E6-F1F5-4045-BCAA-6F8137949CAF@gmail.com> Message-ID: Am Montag, dem 01.04.2024 um 13:38 +0200 schrieb Henning Thielemann: > On Mon, 1 Apr 2024, Iustin Pop wrote: > > > Because the way entire toolchains and the associated libraries are built > > and transitioned, you can't simply upgrade the compiler. A GHC or Perl > > of Python transition in Debian (and thus Ubuntu) takes 1-2 months to > > fully roll out, and more so probably for compiled things such as > > Haskell. Plus, the entire distribution is stabilised before the final > > released. > > > > So you should count at least 6 months, if not a year, before the > > distribution release date. Debian's Haskell group could always use more > > hands as well ;-) > > > > Just use ghcup or a more recent distribution within a VM to debug and > > test. > > One can use Nix to install newer versions even under Ubuntu. I actually > install the Linux binary tarballs and compress them in a squasfs, because > every GHC installation consumes more than a gigaton of harddisk space. Yes, my ~/.ghcup directory has 4.7 Gigabytes... That's a litte heavy. But so what? It's the age of terabyte SSDs. Cheers Volker From post at volker-wysk.de Wed Apr 3 05:44:43 2024 From: post at volker-wysk.de (Volker Wysk) Date: Wed, 03 Apr 2024 07:44:43 +0200 Subject: [Haskell-cafe] Hackage: "Build: PlanningFailed" In-Reply-To: <149A7B8A-AD07-42FC-8A13-967C44FDA581@gmail.com> References: <60d104a71b747f99abea9f101ea100853913167c.camel@volker-wysk.de> <6364b4595482525289613c54ba30e2df6adb0806.camel@volker-wysk.de> <041cc11e5a27b6a53d6e89d2cfff6a3043da7fb5.camel@volker-wysk.de> <9c519a6a0eed414c27b5cd64f511d769c32e5f22.camel@volker-wysk.de> <506BB5E6-F1F5-4045-BCAA-6F8137949CAF@gmail.com> <149A7B8A-AD07-42FC-8A13-967C44FDA581@gmail.com> Message-ID: Am Montag, dem 01.04.2024 um 22:20 +0100 schrieb Andrew Lelechenko: > Just use ghcup (https://www.haskell.org/ghcup/install/)? Done. It seems to work now. But no build report on Hackage... Volker From post at volker-wysk.de Wed Apr 3 05:53:45 2024 From: post at volker-wysk.de (Volker Wysk) Date: Wed, 03 Apr 2024 07:53:45 +0200 Subject: [Haskell-cafe] Announce: HsShellScript 3.6.4 Message-ID: Hi! HsShellScript is a library that lets you do your Unix scripting in Haskell. It was outdated with respect to the supported compiler (meaning base- package) version, but now I've ported it to base >= 4.17.0.0 && < 5 (GHC 9.4/9.5). That's the recommended version (as of 2024-04-02). Here's the homepage: https://volker-wysk.de/hsshellscript/ Cheers, Volker From liyao at pdx.edu Wed Apr 3 15:00:00 2024 From: liyao at pdx.edu (Yao Li) Date: Wed, 3 Apr 2024 08:00:00 -0700 Subject: [Haskell-cafe] PLDI 2024 - Call for Participation (Early registration: May 15) Message-ID: Call for Participation for PLDI 2024, the ACM SIGPLAN Conference on Programming Language Design and Implementation! ------------------------------------------------------------------------ PLDI is a premier forum for programming language research, broadly construed, including design, implementation, theory, applications, and performance. Come join us, online or in Copenhagen, Denmark, to discuss the latest programming languages research! * Website : https://pldi24.sigplan.org/attending/registration * Time : Mon 24--Fri 28 June 2024 * Place : Radisson Blu Scandinavia, Amager Boulevard 70, 2300 Copenhagen S, Denmark ### Important dates * Early Registration: 15th of May, 2024 ### Important rates (Registration rates include a 25% VAT; The prices displayed include tax) Registration rates (in-person) On or before 15 May, 2024 After 15 May, 2024 Regular (ACM or SIGPLAN member) €770.00 €850.00 Regular (non-member) €850.00 €935.00 Student (ACM or SIGPLAN member) €425.00 €505.00 Student (non-member) €475.00 €540.00 Registration rates (virtual) On or before 15 May, 2024 After 15 May, 2024 Regular (ACM or SIGPLAN member) €37.50 €50.00 Regular (non-member) €37.50 €50.00 Student (ACM or SIGPLAN member) €37.50 €50.00 Student (non-member) €37.50 €50.00 1-Day Pass (Co-Located events) On or before 15 May, 2024 After 15 May, 2024 Regular (ACM or SIGPLAN member) €225.00 €250.00 Regular (non-member) €250.00 €275.00 Student (ACM or SIGPLAN member) €150.00 €175.00 Student (non-member) €175.00 €200.00 ### Co-located events: Co-located Conferences: - ISMM, ACM SIGPLAN International Symposium on Memory Management https://conf.researchr.org/home/ismm-2024 - LCTES, ACM SIGPLAN/SIGBED International Conference on Languages, Compilers, and Tools for Embedded Systems https://pldi24.sigplan.org/home/LCTES-2024 Workshops: - ARRAY, the Array Programming Workshop https://pldi24.sigplan.org/home/ARRAY-2024 - CP, International Workshop on Choreographic Programming https://pldi24.sigplan.org/home/cp-2024 - EGRAPHS, the E-Graph Research, Applications, Practices, and Human-factors Symposium https://pldi24.sigplan.org/home/egraphs-2024 - Infer, the Infer Practitioners Workshop https://pldi24.sigplan.org/home/infer-2024 - PLMW, the Programming Languages Mentoring Workshop https://pldi24.sigplan.org/track/PLMW-PLDI-2024 - PODELSKI, PLDI 2024 Workshop Honoring Andreas Podelsk https://pldi24.sigplan.org/home/podelski-2024 - RTFM, Red-Hot Topics in Faculty Mentoring https://pldi24.sigplan.org/home/rtfm-2024 - SOAP, the ACM SIGPLAN International Workshop on the State Of the Art in Program Analysis https://pldi24.sigplan.org/home/SOAP-2024 - Sparse, the Sparse workshop (formerly CTSTA) https://pldi24.sigplan.org/home/sparse-2024 - WQS, Workshop on Quantum Software https://pldi24.sigplan.org/home/wqs-2024 Tutorials: https://pldi24.sigplan.org/track/pldi-2024-tutorials - Algorithms and Applications for Provable Repair of Deep Neural Networks Aditya V. Thakur - Concurrent Algorithms in Kotlin Coroutines Nikita Koval - Democratizing DSL development with the BuildIt Framework Ajay Brahmakshatriya, Saman Amarasinghe - PODELSKI Thomas Wies, Martin Schäf, Andrey Rybalchenko - Quick and dirty development of static analyses with LiSA Luca Negrini, Pietro Ferrara - Static Code Analysis with SootUp Eric Bodden, Markus Schmidt, Jonas Klauke, Kadiray Karakaya, Stefan Schott Student Research Competition! https://pldi24.sigplan.org/track/pldi-2024-src ### Student Volunteering Sign up to be a Volunteer and help us make PLDI 2024 a great experience for all attendants! https://pldi24.sigplan.org/track/pldi-2024-student-volunteering Apply here: https://forms.gle/QB9Tdmhr9v9ZPGx9A. The deadline is 15th of April. Best regards, Yao Li, Ph.D., (He/Him) Assistant Professor, Computer Science Department, Portland State University -------------- next part -------------- An HTML attachment was scrubbed... URL: From matti.johannes.nykanen at gmail.com Thu Apr 4 05:37:08 2024 From: matti.johannes.nykanen at gmail.com (=?UTF-8?Q?Matti_Nyk=C3=A4nen?=) Date: Thu, 4 Apr 2024 08:37:08 +0300 Subject: [Haskell-cafe] PL/Haskell? Message-ID: It seems to be possible to invoke Haskell within PostgreSQL queries, see: (1) Is it popular in the Haskell community? Or is it a proof-of-concept project to show that it can be done? (2) Does it have some easy-to-install packaging? All my initial attempts to follow the online installation instructions have resulted in aggravated lower back pain... -- Matti Nykänen From info.icfpcontest at gmail.com Sun Apr 7 18:00:07 2024 From: info.icfpcontest at gmail.com (ICFP Contest 2024) Date: Sun, 7 Apr 2024 20:00:07 +0200 Subject: [Haskell-cafe] ICFP Programming Contest 2024 Message-ID: Dear Haskell community, The ICFP programming contest 2024 is is held from Friday 28 June 2024 at 12:00 UTC to Monday 1 July 2024 at 12:00 UTC. There will be a lightning division, ending on Saturday 29 June 2024 at 12:00 UTC. This is the 27th instance of the annual programming contest series sponsored by the ACM SIGPLAN International Conference on Functional Programming. This is an open online programming contest. Anybody may participate except for the contest organisers. No advance registration or entry fee is required. Contestants are free to organize themselves into teams of any size. Any programming language(s) on any platform(s) may be used. As a member of this community, you are all invited to participate. For more information and contact details, see https://icfpcontest2024.github.io/ We hope to see many of you on the scoreboard the end of June! Functional greetings, The ICFP Contest 2024 organising committee From mukeshtiwari.iiitm at gmail.com Mon Apr 8 08:09:06 2024 From: mukeshtiwari.iiitm at gmail.com (mukesh tiwari) Date: Mon, 8 Apr 2024 09:09:06 +0100 Subject: [Haskell-cafe] Agda Implementors' Meeting XXXVIII: Call for talks and participation Message-ID: Dear all, The thirty-eighth Agda Implementors' Meeting will take place in Swansea, Wales, UK from Monday 13 to Saturday 18 May 2024. Wiki link for more details: https://wiki.portal.chalmers.se/ agda /Main/AIMXXXVIII The meeting aims to bring together people not only developing but also using Agda or even those who are simply interested in it. We will have talks on the implementation details of Agda in the morning and code sprints in the afternoon. You can still submit your proposal for a talk or discussion! There's a (soft) deadline for registration on 14 April 2024 Registration instructions: https://wiki.portal.chalmers.se/ agda /Main/AIMXXXVIII#Registration Best wishes, Anton Setzer ----------------------------------------------------------------------------- Dr Anton Setzer Darllenydd / Reader Ystafell / Room 403 Adran Gyfrifiadureg / Dept. of Computer Science Y Ffowndri Gyfrifiadurol / Computational Foundry Coleg Gwyddoniaeth / College of Science Prifysgol Abertawe/ Swansea University Campws y Bae/ Bay Campus Abertawe / Swansea SA1 8EN DU / UK Rhowch wybod i ni os hoffech dderbyn eich gohebiaeth yn Gymraeg. / Let us know if you would like to receive correspondence in Welsh. Rydym yn croesawu gohebiaeth yn Gymraeg neu yn Saesneg. / We welcome correspondence in Welsh or English. Ni fydd gohebu yn Gymraeg yn arwain at oedi./ Corresponding in Welsh will not lead to a delay. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ifl21.publicity at gmail.com Tue Apr 9 09:15:30 2024 From: ifl21.publicity at gmail.com (Mart Lubbers) Date: Tue, 9 Apr 2024 02:15:30 -0700 Subject: [Haskell-cafe] IFL 2024: First call for papers Message-ID: ======================================================================= IFL 2024 36rd Symposium on Implementation and Application of Functional Languages venue: Radboud University Nijmegen, The Netherlands August 26 - 28 2024 https://ifl24.cs.ru.nl ======================================================================= ### Scope The goal of the IFL symposia is to bring together researchers actively engaged in the implementation and application of functional and function-based programming languages. IFL 2024 will be a venue for researchers to present and discuss new ideas and concepts, work in progress, and publication-ripe results related to the implementation and application of functional languages and function-based programming. ### Industrial track and topics of interest Topics of interest to IFL include, but are not limited to: - language concepts - type systems, type checking, type inferencing - compilation techniques - staged compilation - run-time function specialisation - run-time code generation - partial evaluation - (abstract) interpretation - meta-programming - generic programming - automatic program generation - array processing - concurrent/parallel programming - concurrent/parallel program execution - embedded systems - web applications - (embedded) domain specific languages - security - novel memory management techniques - run-time profiling performance measurements - debugging and tracing - virtual/abstract machine architectures - validation, verification of functional programs - tools and programming techniques ### Peer-review process Following IFL tradition, IFL 2024 will use a post-symposium review process to produce the formal proceedings. Before the symposium authors submit draft papers. These draft papers will be screened by the program chairs to make sure that they are within the scope of IFL. The draft papers will be made available to all participants at the symposium. Each draft paper is presented by one of the authors at the symposium. After the symposium, a formal review process will take place, conducted by the program committee. Reviewing is single blind. There will be at least 3 reviews per paper. The reviewers have 6 weeks to write their reviews. For the camera-ready version the authors can make minor revisions which are accepted without further reviewing. ### Important dates Submission deadline of draft papers August 4th, 2024 Notification of acceptance for presentation August 6th, 2024 Early registration deadline August 11th, 2024 Late registration deadline August 21th, 2024 IFL symposium August 26-28, 2024 Submission of papers for proceedings December 1st, 2024 Notification of acceptance February 2nd, 2025 Camera-ready version March 2nd, 2025 ### Submission details All contributions must be written in English. Papers must use the ACM two columns conference format, which can be found at: http://www.acm.org/publications/proceedings-template ### Peter Landin Prize The Peter Landin Prize is awarded to the best paper presented at the symposium every year. The honoured article is selected by the program committee based on the submissions received for the formal review process. The prize carries a cash award equivalent to 150 Euros. ### Organisation PC Chairs: Mart Lubbers Radboud University, The Netherlands Local Chairs: Peter Achten Radboud University, The Netherlands Sven-Bodo Scholz, Radboud University, The Netherlands ### Program committee: t.b.d. ### Venue IFL 2024 will be held physically in Nijmegen, the Netherlands. See the website for more information. https://ifl24.cs.ru.nl (under construction) ### Acknowledgments This call-for-papers is an adaptation and evolution of content from previous instances of IFL. We are grateful to prior organisers for their work, which is reused here. From han.joosten.han at gmail.com Tue Apr 9 10:18:14 2024 From: han.joosten.han at gmail.com (Han Joosten) Date: Tue, 9 Apr 2024 12:18:14 +0200 Subject: [Haskell-cafe] Ambiguous occurence error, despite use of DuplicateRecordFields (worked with ghc 8.10.7, not with 9.6.4) Message-ID: Hi all, I am currently migrating a Haskell project that uses ghc 8.10.7 to ghc 9.6.4. Using the new version, I get errors like ~~~.haskell Ambiguous occurrence ‘pos’ It could refer to either the field ‘pos’ of record ‘PClassify’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:1265:5 or the field ‘pos’ of record ‘PPurpose’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:1186:5 or the field ‘pos’ of record ‘P_ViewSegment’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:1129:5 or the field ‘pos’ of record ‘P_ViewD’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:1080:5 or the field ‘pos’ of record ‘P_IdentDf’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:1024:5 or the field ‘pos’ of record ‘P_BoxItem’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:981:9 or the field ‘pos’ of record ‘TemplateKeyValue’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:959:5 or the field ‘pos’ of record ‘BoxHeader’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:947:5 or the field ‘pos’ of record ‘P_SubIfc’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:934:9 or the field ‘pos’ of record ‘P_Interface’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:899:5 or the field ‘pos’ of record ‘P_Population’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:870:9 or the field ‘pos’ of record ‘P_Rule’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:806:5 or the field ‘pos’ of record ‘PairViewSegment’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:740:9 or the field ‘pos’ of record ‘P_NamedRel’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:591:5 or the field ‘pos’ of record ‘PAtomPair’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:467:5 or the field ‘pos’ of record ‘Pragma’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:415:5 or the field ‘pos’ of record ‘P_Relation’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:408:5 or the field ‘pos’ of record ‘Representation’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:339:5 or the field ‘pos’ of record ‘PConceptDef’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:268:5 or the field ‘pos’ of record ‘P_Pattern’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:209:5 or the field ‘pos’ of record ‘Role’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:185:5 or the field ‘pos’ of record ‘P_RoleRule’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:172:5 or the field ‘pos’ of record ‘P_Enforce’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:152:5 or the field ‘pos’ of record ‘MetaData’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:136:5 Previously, it was totally fine to have different data types each have a field with the same name, as long as you used `DuplicateRecordFields` I have searched the migration documentation but I couldn't find any clue on why this has been changed or how to deal with it. I probably missed it. Any help is mostly appreciated! Thanks for reading Cheers, Han Joosten -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom-lists-haskell-cafe-2023 at jaguarpaw.co.uk Tue Apr 9 10:37:36 2024 From: tom-lists-haskell-cafe-2023 at jaguarpaw.co.uk (Tom Ellis) Date: Tue, 9 Apr 2024 11:37:36 +0100 Subject: [Haskell-cafe] Ambiguous occurence error, despite use of DuplicateRecordFields (worked with ghc 8.10.7, not with 9.6.4) In-Reply-To: References: Message-ID: Hello Han, Would it be possible to produce a minimal example that demonstrates the problem? Or at the very least share the code? It's very hard to know where to start diagnosing. (Although perhaps someone else knows without having to see code.) At a wild guess, have you been hit by this? > As of GHC 9.4.1, selector names have to be entirely unambiguous > (under the usual name resolution rules), while for record updates, > there must be at most one datatype that has all the field names > being updated. https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/duplicate_record_fields.html#extension-DuplicateRecordFields Tom On Tue, Apr 09, 2024 at 12:18:14PM +0200, Han Joosten wrote: > Hi all, > > I am currently migrating a Haskell project that uses ghc 8.10.7 to ghc > 9.6.4. > > Using the new version, I get errors like > > ~~~.haskell > Ambiguous occurrence ‘pos’ > It could refer to > either the field ‘pos’ of record ‘PClassify’, > defined at > /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:1265:5 > or the field ‘pos’ of record ‘PPurpose’, > defined at > /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:1186:5 > or the field ‘pos’ of record ‘P_ViewSegment’, > defined at > /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:1129:5 > or the field ‘pos’ of record ‘P_ViewD’, > defined at > /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:1080:5 > or the field ‘pos’ of record ‘P_IdentDf’, > defined at > /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:1024:5 > or the field ‘pos’ of record ‘P_BoxItem’, > defined at > /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:981:9 > or the field ‘pos’ of record ‘TemplateKeyValue’, > defined at > /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:959:5 > or the field ‘pos’ of record ‘BoxHeader’, > defined at > /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:947:5 > or the field ‘pos’ of record ‘P_SubIfc’, > defined at > /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:934:9 > or the field ‘pos’ of record ‘P_Interface’, > defined at > /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:899:5 > or the field ‘pos’ of record ‘P_Population’, > defined at > /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:870:9 > or the field ‘pos’ of record ‘P_Rule’, > defined at > /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:806:5 > or the field ‘pos’ of record ‘PairViewSegment’, > defined at > /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:740:9 > or the field ‘pos’ of record ‘P_NamedRel’, > defined at > /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:591:5 > or the field ‘pos’ of record ‘PAtomPair’, > defined at > /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:467:5 > or the field ‘pos’ of record ‘Pragma’, > defined at > /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:415:5 > or the field ‘pos’ of record ‘P_Relation’, > defined at > /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:408:5 > or the field ‘pos’ of record ‘Representation’, > defined at > /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:339:5 > or the field ‘pos’ of record ‘PConceptDef’, > defined at > /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:268:5 > or the field ‘pos’ of record ‘P_Pattern’, > defined at > /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:209:5 > or the field ‘pos’ of record ‘Role’, > defined at > /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:185:5 > or the field ‘pos’ of record ‘P_RoleRule’, > defined at > /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:172:5 > or the field ‘pos’ of record ‘P_Enforce’, > defined at > /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:152:5 > or the field ‘pos’ of record ‘MetaData’, > defined at > /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:136:5 > > Previously, it was totally fine to have different data types each have a > field with the same name, as long as you used `DuplicateRecordFields` > > I have searched the migration documentation but I couldn't find any clue on > why this has been changed or how to deal with it. I probably missed it. > Any help is mostly appreciated! > > Thanks for reading > Cheers, > Han Joosten > _______________________________________________ > 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 han.joosten.han at gmail.com Tue Apr 9 11:57:48 2024 From: han.joosten.han at gmail.com (Han Joosten) Date: Tue, 9 Apr 2024 13:57:48 +0200 Subject: [Haskell-cafe] Ambiguous occurence error, despite use of DuplicateRecordFields (worked with ghc 8.10.7, not with 9.6.4) In-Reply-To: References: Message-ID: Hi Tom, The code can be found here: https://github.com/AmpersandTarski/Ampersand/blob/upgrade-ghc/src/Ampersand/Core/ParseTree.hs The idea is that I have several data definitions each with a field named `pos`. I have a class that conveniently gets that field from whatever instance. This used to work, but now is broken: data Foo = Foo { pos :: !Origin, ... other fields } data Bar = Bar { pos :: !Origin, ... other fields } class Traced a where origin :: a -> Origin instance Traced Foo where origin = pos instance Traced Bar where origin = pos Of course I could rewrite the instance definitions something like instance Traced Foo where origin (Foo{pos = p} = p but that looks ugly, and it feels strange. Thanks for replying Op di 9 apr 2024 om 12:38 schreef Tom Ellis < tom-lists-haskell-cafe-2023 at jaguarpaw.co.uk>: > Hello Han, > > Would it be possible to produce a minimal example that demonstrates > the problem? Or at the very least share the code? It's very hard to > know where to start diagnosing. (Although perhaps someone else knows > without having to see code.) > > At a wild guess, have you been hit by this? > > > As of GHC 9.4.1, selector names have to be entirely unambiguous > > (under the usual name resolution rules), while for record updates, > > there must be at most one datatype that has all the field names > > being updated. > > > https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/duplicate_record_fields.html#extension-DuplicateRecordFields > > Tom > > > > On Tue, Apr 09, 2024 at 12:18:14PM +0200, Han Joosten wrote: > > Hi all, > > > > I am currently migrating a Haskell project that uses ghc 8.10.7 to ghc > > 9.6.4. > > > > Using the new version, I get errors like > > > > ~~~.haskell > > Ambiguous occurrence ‘pos’ > > It could refer to > > either the field ‘pos’ of record ‘PClassify’, > > defined at > > /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:1265:5 > > or the field ‘pos’ of record ‘PPurpose’, > > defined at > > /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:1186:5 > > or the field ‘pos’ of record ‘P_ViewSegment’, > > defined at > > /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:1129:5 > > or the field ‘pos’ of record ‘P_ViewD’, > > defined at > > /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:1080:5 > > or the field ‘pos’ of record ‘P_IdentDf’, > > defined at > > /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:1024:5 > > or the field ‘pos’ of record ‘P_BoxItem’, > > defined at > > /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:981:9 > > or the field ‘pos’ of record ‘TemplateKeyValue’, > > defined at > > /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:959:5 > > or the field ‘pos’ of record ‘BoxHeader’, > > defined at > > /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:947:5 > > or the field ‘pos’ of record ‘P_SubIfc’, > > defined at > > /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:934:9 > > or the field ‘pos’ of record ‘P_Interface’, > > defined at > > /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:899:5 > > or the field ‘pos’ of record ‘P_Population’, > > defined at > > /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:870:9 > > or the field ‘pos’ of record ‘P_Rule’, > > defined at > > /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:806:5 > > or the field ‘pos’ of record ‘PairViewSegment’, > > defined at > > /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:740:9 > > or the field ‘pos’ of record ‘P_NamedRel’, > > defined at > > /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:591:5 > > or the field ‘pos’ of record ‘PAtomPair’, > > defined at > > /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:467:5 > > or the field ‘pos’ of record ‘Pragma’, > > defined at > > /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:415:5 > > or the field ‘pos’ of record ‘P_Relation’, > > defined at > > /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:408:5 > > or the field ‘pos’ of record ‘Representation’, > > defined at > > /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:339:5 > > or the field ‘pos’ of record ‘PConceptDef’, > > defined at > > /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:268:5 > > or the field ‘pos’ of record ‘P_Pattern’, > > defined at > > /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:209:5 > > or the field ‘pos’ of record ‘Role’, > > defined at > > /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:185:5 > > or the field ‘pos’ of record ‘P_RoleRule’, > > defined at > > /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:172:5 > > or the field ‘pos’ of record ‘P_Enforce’, > > defined at > > /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:152:5 > > or the field ‘pos’ of record ‘MetaData’, > > defined at > > /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:136:5 > > > > Previously, it was totally fine to have different data types each have a > > field with the same name, as long as you used `DuplicateRecordFields` > > > > I have searched the migration documentation but I couldn't find any clue > on > > why this has been changed or how to deal with it. I probably missed it. > > Any help is mostly appreciated! > > > > Thanks for reading > > Cheers, > > Han Joosten > > > _______________________________________________ > > 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 tom-lists-haskell-cafe-2023 at jaguarpaw.co.uk Tue Apr 9 12:17:47 2024 From: tom-lists-haskell-cafe-2023 at jaguarpaw.co.uk (Tom Ellis) Date: Tue, 9 Apr 2024 13:17:47 +0100 Subject: [Haskell-cafe] Ambiguous occurence error, despite use of DuplicateRecordFields (worked with ghc 8.10.7, not with 9.6.4) In-Reply-To: References: Message-ID: I see, thanks. So it does look like my wild guess was correct. GHC will no longer disambiguate ambiguous field selectors. Perhaps you're supposed to use OverloadedRecordDot for this (I'm not sure, I don't use it myself). Tom On Tue, Apr 09, 2024 at 01:57:48PM +0200, Han Joosten wrote: > The code can be found here: > https://github.com/AmpersandTarski/Ampersand/blob/upgrade-ghc/src/Ampersand/Core/ParseTree.hs > > The idea is that I have several data definitions each with a field named > `pos`. I have a class that conveniently gets that field from whatever > instance. This used to work, but now is broken: > > data Foo = Foo > { pos :: !Origin, > ... other fields > } > data Bar = Bar > { pos :: !Origin, > ... other fields > } > > class Traced a where > origin :: a -> Origin > > instance Traced Foo where > origin = pos > > instance Traced Bar where > origin = pos > > Of course I could rewrite the instance definitions something like > > instance Traced Foo where > origin (Foo{pos = p} = p > > Op di 9 apr 2024 om 12:38 schreef Tom Ellis < > tom-lists-haskell-cafe-2023 at jaguarpaw.co.uk>: > > Would it be possible to produce a minimal example that demonstrates > > the problem? Or at the very least share the code? It's very hard to > > know where to start diagnosing. (Although perhaps someone else knows > > without having to see code.) > > > > At a wild guess, have you been hit by this? > > > > > As of GHC 9.4.1, selector names have to be entirely unambiguous > > > (under the usual name resolution rules), while for record updates, > > > there must be at most one datatype that has all the field names > > > being updated. > > > > https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/duplicate_record_fields.html#extension-DuplicateRecordFields > > > > On Tue, Apr 09, 2024 at 12:18:14PM +0200, Han Joosten wrote: > > > Hi all, > > > > > > I am currently migrating a Haskell project that uses ghc 8.10.7 to ghc > > > 9.6.4. > > > > > > Using the new version, I get errors like > > > > > > ~~~.haskell > > > Ambiguous occurrence ‘pos’ > > > It could refer to > > > either the field ‘pos’ of record ‘PClassify’, > > > defined at > > > /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:1265:5 > > > or the field ‘pos’ of record ‘PPurpose’, > > > defined at > > > /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:1186:5 > > > or the field ‘pos’ of record ‘P_ViewSegment’, > > > defined at > > > /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:1129:5 > > > or the field ‘pos’ of record ‘P_ViewD’, > > > defined at > > > /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:1080:5 > > > or the field ‘pos’ of record ‘P_IdentDf’, > > > defined at > > > /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:1024:5 > > > or the field ‘pos’ of record ‘P_BoxItem’, > > > defined at > > > /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:981:9 > > > or the field ‘pos’ of record ‘TemplateKeyValue’, > > > defined at > > > /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:959:5 > > > or the field ‘pos’ of record ‘BoxHeader’, > > > defined at > > > /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:947:5 > > > or the field ‘pos’ of record ‘P_SubIfc’, > > > defined at > > > /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:934:9 > > > or the field ‘pos’ of record ‘P_Interface’, > > > defined at > > > /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:899:5 > > > or the field ‘pos’ of record ‘P_Population’, > > > defined at > > > /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:870:9 > > > or the field ‘pos’ of record ‘P_Rule’, > > > defined at > > > /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:806:5 > > > or the field ‘pos’ of record ‘PairViewSegment’, > > > defined at > > > /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:740:9 > > > or the field ‘pos’ of record ‘P_NamedRel’, > > > defined at > > > /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:591:5 > > > or the field ‘pos’ of record ‘PAtomPair’, > > > defined at > > > /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:467:5 > > > or the field ‘pos’ of record ‘Pragma’, > > > defined at > > > /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:415:5 > > > or the field ‘pos’ of record ‘P_Relation’, > > > defined at > > > /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:408:5 > > > or the field ‘pos’ of record ‘Representation’, > > > defined at > > > /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:339:5 > > > or the field ‘pos’ of record ‘PConceptDef’, > > > defined at > > > /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:268:5 > > > or the field ‘pos’ of record ‘P_Pattern’, > > > defined at > > > /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:209:5 > > > or the field ‘pos’ of record ‘Role’, > > > defined at > > > /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:185:5 > > > or the field ‘pos’ of record ‘P_RoleRule’, > > > defined at > > > /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:172:5 > > > or the field ‘pos’ of record ‘P_Enforce’, > > > defined at > > > /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:152:5 > > > or the field ‘pos’ of record ‘MetaData’, > > > defined at > > > /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:136:5 > > > > > > Previously, it was totally fine to have different data types each have a > > > field with the same name, as long as you used `DuplicateRecordFields` > > > > > > I have searched the migration documentation but I couldn't find any clue > > on > > > why this has been changed or how to deal with it. I probably missed it. > > > Any help is mostly appreciated! > > > > > > Thanks for reading > > > Cheers, > > > Han Joosten > > > > > _______________________________________________ > > > 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. > _______________________________________________ > 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-2023 at jaguarpaw.co.uk Tue Apr 9 13:01:27 2024 From: tom-lists-haskell-cafe-2023 at jaguarpaw.co.uk (Tom Ellis) Date: Tue, 9 Apr 2024 14:01:27 +0100 Subject: [Haskell-cafe] Ambiguous occurence error, despite use of DuplicateRecordFields (worked with ghc 8.10.7, not with 9.6.4) In-Reply-To: References: Message-ID: By the way, how are you compiling this? I tried $ cabal build -w ghc-9.6 on branch upgrade-ghc but I get a cabal resolver error. Tom On Tue, Apr 09, 2024 at 01:17:47PM +0100, Tom Ellis wrote: > I see, thanks. So it does look like my wild guess was correct. GHC > will no longer disambiguate ambiguous field selectors. Perhaps you're > supposed to use OverloadedRecordDot for this (I'm not sure, I don't > use it myself). > > On Tue, Apr 09, 2024 at 01:57:48PM +0200, Han Joosten wrote: > > The code can be found here: > > https://github.com/AmpersandTarski/Ampersand/blob/upgrade-ghc/src/Ampersand/Core/ParseTree.hs > > > > The idea is that I have several data definitions each with a field named > > `pos`. I have a class that conveniently gets that field from whatever > > instance. This used to work, but now is broken: > > > > data Foo = Foo > > { pos :: !Origin, > > ... other fields > > } > > data Bar = Bar > > { pos :: !Origin, > > ... other fields > > } > > > > class Traced a where > > origin :: a -> Origin > > > > instance Traced Foo where > > origin = pos > > > > instance Traced Bar where > > origin = pos > > > > Of course I could rewrite the instance definitions something like > > > > instance Traced Foo where > > origin (Foo{pos = p} = p > > > > Op di 9 apr 2024 om 12:38 schreef Tom Ellis < > > tom-lists-haskell-cafe-2023 at jaguarpaw.co.uk>: > > > Would it be possible to produce a minimal example that demonstrates > > > the problem? Or at the very least share the code? It's very hard to > > > know where to start diagnosing. (Although perhaps someone else knows > > > without having to see code.) > > > > > > At a wild guess, have you been hit by this? > > > > > > > As of GHC 9.4.1, selector names have to be entirely unambiguous > > > > (under the usual name resolution rules), while for record updates, > > > > there must be at most one datatype that has all the field names > > > > being updated. > > > > > > https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/duplicate_record_fields.html#extension-DuplicateRecordFields > > > > > > On Tue, Apr 09, 2024 at 12:18:14PM +0200, Han Joosten wrote: > > > > Hi all, > > > > > > > > I am currently migrating a Haskell project that uses ghc 8.10.7 to ghc > > > > 9.6.4. > > > > > > > > Using the new version, I get errors like > > > > > > > > ~~~.haskell > > > > Ambiguous occurrence ‘pos’ > > > > It could refer to > > > > either the field ‘pos’ of record ‘PClassify’, > > > > defined at > > > > /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:1265:5 > > > > or the field ‘pos’ of record ‘PPurpose’, > > > > defined at > > > > /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:1186:5 > > > > or the field ‘pos’ of record ‘P_ViewSegment’, > > > > defined at > > > > /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:1129:5 > > > > or the field ‘pos’ of record ‘P_ViewD’, > > > > defined at > > > > /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:1080:5 > > > > or the field ‘pos’ of record ‘P_IdentDf’, > > > > defined at > > > > /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:1024:5 > > > > or the field ‘pos’ of record ‘P_BoxItem’, > > > > defined at > > > > /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:981:9 > > > > or the field ‘pos’ of record ‘TemplateKeyValue’, > > > > defined at > > > > /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:959:5 > > > > or the field ‘pos’ of record ‘BoxHeader’, > > > > defined at > > > > /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:947:5 > > > > or the field ‘pos’ of record ‘P_SubIfc’, > > > > defined at > > > > /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:934:9 > > > > or the field ‘pos’ of record ‘P_Interface’, > > > > defined at > > > > /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:899:5 > > > > or the field ‘pos’ of record ‘P_Population’, > > > > defined at > > > > /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:870:9 > > > > or the field ‘pos’ of record ‘P_Rule’, > > > > defined at > > > > /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:806:5 > > > > or the field ‘pos’ of record ‘PairViewSegment’, > > > > defined at > > > > /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:740:9 > > > > or the field ‘pos’ of record ‘P_NamedRel’, > > > > defined at > > > > /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:591:5 > > > > or the field ‘pos’ of record ‘PAtomPair’, > > > > defined at > > > > /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:467:5 > > > > or the field ‘pos’ of record ‘Pragma’, > > > > defined at > > > > /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:415:5 > > > > or the field ‘pos’ of record ‘P_Relation’, > > > > defined at > > > > /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:408:5 > > > > or the field ‘pos’ of record ‘Representation’, > > > > defined at > > > > /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:339:5 > > > > or the field ‘pos’ of record ‘PConceptDef’, > > > > defined at > > > > /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:268:5 > > > > or the field ‘pos’ of record ‘P_Pattern’, > > > > defined at > > > > /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:209:5 > > > > or the field ‘pos’ of record ‘Role’, > > > > defined at > > > > /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:185:5 > > > > or the field ‘pos’ of record ‘P_RoleRule’, > > > > defined at > > > > /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:172:5 > > > > or the field ‘pos’ of record ‘P_Enforce’, > > > > defined at > > > > /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:152:5 > > > > or the field ‘pos’ of record ‘MetaData’, > > > > defined at > > > > /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:136:5 > > > > > > > > Previously, it was totally fine to have different data types each have a > > > > field with the same name, as long as you used `DuplicateRecordFields` > > > > > > > > I have searched the migration documentation but I couldn't find any clue > > > on > > > > why this has been changed or how to deal with it. I probably missed it. > > > > Any help is mostly appreciated! > > > > > > > > Thanks for reading > > > > Cheers, > > > > Han Joosten > > > > > > > _______________________________________________ > > > > 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. > > > _______________________________________________ > > 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 han.joosten.han at gmail.com Wed Apr 10 06:43:08 2024 From: han.joosten.han at gmail.com (Han Joosten) Date: Wed, 10 Apr 2024 08:43:08 +0200 Subject: [Haskell-cafe] Ambiguous occurence error, despite use of DuplicateRecordFields (worked with ghc 8.10.7, not with 9.6.4) In-Reply-To: References: Message-ID: I figured out to go for the easy way, not to figure out all the (fancy?) language pragma's. I will just rewrite the broken bits. Not hard to do, mostly annoying and less concise. I use stack to build. That way I know exactly the versions that will be used for each and every dependency. Thanks for helping out! Han. Op di 9 apr 2024 om 15:01 schreef Tom Ellis < tom-lists-haskell-cafe-2023 at jaguarpaw.co.uk>: > By the way, how are you compiling this? I tried > > $ cabal build -w ghc-9.6 > > on branch upgrade-ghc but I get a cabal resolver error. > > Tom > > > On Tue, Apr 09, 2024 at 01:17:47PM +0100, Tom Ellis wrote: > > I see, thanks. So it does look like my wild guess was correct. GHC > > will no longer disambiguate ambiguous field selectors. Perhaps you're > > supposed to use OverloadedRecordDot for this (I'm not sure, I don't > > use it myself). > > > > On Tue, Apr 09, 2024 at 01:57:48PM +0200, Han Joosten wrote: > > > The code can be found here: > > > > https://github.com/AmpersandTarski/Ampersand/blob/upgrade-ghc/src/Ampersand/Core/ParseTree.hs > > > > > > The idea is that I have several data definitions each with a field > named > > > `pos`. I have a class that conveniently gets that field from whatever > > > instance. This used to work, but now is broken: > > > > > > data Foo = Foo > > > { pos :: !Origin, > > > ... other fields > > > } > > > data Bar = Bar > > > { pos :: !Origin, > > > ... other fields > > > } > > > > > > class Traced a where > > > origin :: a -> Origin > > > > > > instance Traced Foo where > > > origin = pos > > > > > > instance Traced Bar where > > > origin = pos > > > > > > Of course I could rewrite the instance definitions something like > > > > > > instance Traced Foo where > > > origin (Foo{pos = p} = p > > > > > > Op di 9 apr 2024 om 12:38 schreef Tom Ellis < > > > tom-lists-haskell-cafe-2023 at jaguarpaw.co.uk>: > > > > Would it be possible to produce a minimal example that demonstrates > > > > the problem? Or at the very least share the code? It's very hard to > > > > know where to start diagnosing. (Although perhaps someone else knows > > > > without having to see code.) > > > > > > > > At a wild guess, have you been hit by this? > > > > > > > > > As of GHC 9.4.1, selector names have to be entirely unambiguous > > > > > (under the usual name resolution rules), while for record updates, > > > > > there must be at most one datatype that has all the field names > > > > > being updated. > > > > > > > > > https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/duplicate_record_fields.html#extension-DuplicateRecordFields > > > > > > > > On Tue, Apr 09, 2024 at 12:18:14PM +0200, Han Joosten wrote: > > > > > Hi all, > > > > > > > > > > I am currently migrating a Haskell project that uses ghc 8.10.7 to > ghc > > > > > 9.6.4. > > > > > > > > > > Using the new version, I get errors like > > > > > > > > > > ~~~.haskell > > > > > Ambiguous occurrence ‘pos’ > > > > > It could refer to > > > > > either the field ‘pos’ of record ‘PClassify’, > > > > > defined at > > > > > > /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:1265:5 > > > > > or the field ‘pos’ of record ‘PPurpose’, > > > > > defined at > > > > > > /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:1186:5 > > > > > or the field ‘pos’ of record ‘P_ViewSegment’, > > > > > defined at > > > > > > /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:1129:5 > > > > > or the field ‘pos’ of record ‘P_ViewD’, > > > > > defined at > > > > > > /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:1080:5 > > > > > or the field ‘pos’ of record ‘P_IdentDf’, > > > > > defined at > > > > > > /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:1024:5 > > > > > or the field ‘pos’ of record ‘P_BoxItem’, > > > > > defined at > > > > > > /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:981:9 > > > > > or the field ‘pos’ of record ‘TemplateKeyValue’, > > > > > defined at > > > > > > /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:959:5 > > > > > or the field ‘pos’ of record ‘BoxHeader’, > > > > > defined at > > > > > > /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:947:5 > > > > > or the field ‘pos’ of record ‘P_SubIfc’, > > > > > defined at > > > > > > /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:934:9 > > > > > or the field ‘pos’ of record ‘P_Interface’, > > > > > defined at > > > > > > /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:899:5 > > > > > or the field ‘pos’ of record ‘P_Population’, > > > > > defined at > > > > > > /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:870:9 > > > > > or the field ‘pos’ of record ‘P_Rule’, > > > > > defined at > > > > > > /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:806:5 > > > > > or the field ‘pos’ of record ‘PairViewSegment’, > > > > > defined at > > > > > > /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:740:9 > > > > > or the field ‘pos’ of record ‘P_NamedRel’, > > > > > defined at > > > > > > /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:591:5 > > > > > or the field ‘pos’ of record ‘PAtomPair’, > > > > > defined at > > > > > > /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:467:5 > > > > > or the field ‘pos’ of record ‘Pragma’, > > > > > defined at > > > > > > /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:415:5 > > > > > or the field ‘pos’ of record ‘P_Relation’, > > > > > defined at > > > > > > /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:408:5 > > > > > or the field ‘pos’ of record ‘Representation’, > > > > > defined at > > > > > > /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:339:5 > > > > > or the field ‘pos’ of record ‘PConceptDef’, > > > > > defined at > > > > > > /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:268:5 > > > > > or the field ‘pos’ of record ‘P_Pattern’, > > > > > defined at > > > > > > /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:209:5 > > > > > or the field ‘pos’ of record ‘Role’, > > > > > defined at > > > > > > /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:185:5 > > > > > or the field ‘pos’ of record ‘P_RoleRule’, > > > > > defined at > > > > > > /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:172:5 > > > > > or the field ‘pos’ of record ‘P_Enforce’, > > > > > defined at > > > > > > /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:152:5 > > > > > or the field ‘pos’ of record ‘MetaData’, > > > > > defined at > > > > > > /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:136:5 > > > > > > > > > > Previously, it was totally fine to have different data types each > have a > > > > > field with the same name, as long as you used > `DuplicateRecordFields` > > > > > > > > > > I have searched the migration documentation but I couldn't find > any clue > > > > on > > > > > why this has been changed or how to deal with it. I probably > missed it. > > > > > Any help is mostly appreciated! > > > > > > > > > > Thanks for reading > > > > > Cheers, > > > > > Han Joosten > > > > > > > > > _______________________________________________ > > > > > 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. > > > > > _______________________________________________ > > > 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. > _______________________________________________ > 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-2023 at jaguarpaw.co.uk Wed Apr 10 06:52:49 2024 From: tom-lists-haskell-cafe-2023 at jaguarpaw.co.uk (Tom Ellis) Date: Wed, 10 Apr 2024 07:52:49 +0100 Subject: [Haskell-cafe] Ambiguous occurence error, despite use of DuplicateRecordFields (worked with ghc 8.10.7, not with 9.6.4) In-Reply-To: References: Message-ID: Perhaps this trick may help you? https://discourse.haskell.org/t/how-to-do-user-facing-records-in-2024/9176/23 On Wed, Apr 10, 2024 at 08:43:08AM +0200, Han Joosten wrote: > I figured out to go for the easy way, not to figure out all the (fancy?) > language pragma's. I will just rewrite the broken bits. Not hard to do, > mostly annoying and less concise. > I use stack to build. That way I know exactly the versions that will be > used for each and every dependency. > > Thanks for helping out! > Han. > > Op di 9 apr 2024 om 15:01 schreef Tom Ellis < > tom-lists-haskell-cafe-2023 at jaguarpaw.co.uk>: > > > By the way, how are you compiling this? I tried > > > > $ cabal build -w ghc-9.6 > > > > on branch upgrade-ghc but I get a cabal resolver error. > > > > Tom > > > > > > On Tue, Apr 09, 2024 at 01:17:47PM +0100, Tom Ellis wrote: > > > I see, thanks. So it does look like my wild guess was correct. GHC > > > will no longer disambiguate ambiguous field selectors. Perhaps you're > > > supposed to use OverloadedRecordDot for this (I'm not sure, I don't > > > use it myself). > > > > > > On Tue, Apr 09, 2024 at 01:57:48PM +0200, Han Joosten wrote: > > > > The code can be found here: > > > > > > https://github.com/AmpersandTarski/Ampersand/blob/upgrade-ghc/src/Ampersand/Core/ParseTree.hs > > > > > > > > The idea is that I have several data definitions each with a field > > named > > > > `pos`. I have a class that conveniently gets that field from whatever > > > > instance. This used to work, but now is broken: > > > > > > > > data Foo = Foo > > > > { pos :: !Origin, > > > > ... other fields > > > > } > > > > data Bar = Bar > > > > { pos :: !Origin, > > > > ... other fields > > > > } > > > > > > > > class Traced a where > > > > origin :: a -> Origin > > > > > > > > instance Traced Foo where > > > > origin = pos > > > > > > > > instance Traced Bar where > > > > origin = pos > > > > > > > > Of course I could rewrite the instance definitions something like > > > > > > > > instance Traced Foo where > > > > origin (Foo{pos = p} = p > > > > > > > > Op di 9 apr 2024 om 12:38 schreef Tom Ellis < > > > > tom-lists-haskell-cafe-2023 at jaguarpaw.co.uk>: > > > > > Would it be possible to produce a minimal example that demonstrates > > > > > the problem? Or at the very least share the code? It's very hard to > > > > > know where to start diagnosing. (Although perhaps someone else knows > > > > > without having to see code.) > > > > > > > > > > At a wild guess, have you been hit by this? > > > > > > > > > > > As of GHC 9.4.1, selector names have to be entirely unambiguous > > > > > > (under the usual name resolution rules), while for record updates, > > > > > > there must be at most one datatype that has all the field names > > > > > > being updated. > > > > > > > > > > > > https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/duplicate_record_fields.html#extension-DuplicateRecordFields > > > > > > > > > > On Tue, Apr 09, 2024 at 12:18:14PM +0200, Han Joosten wrote: > > > > > > Hi all, > > > > > > > > > > > > I am currently migrating a Haskell project that uses ghc 8.10.7 to > > ghc > > > > > > 9.6.4. > > > > > > > > > > > > Using the new version, I get errors like > > > > > > > > > > > > ~~~.haskell > > > > > > Ambiguous occurrence ‘pos’ > > > > > > It could refer to > > > > > > either the field ‘pos’ of record ‘PClassify’, > > > > > > defined at > > > > > > > > /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:1265:5 > > > > > > or the field ‘pos’ of record ‘PPurpose’, > > > > > > defined at > > > > > > > > /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:1186:5 > > > > > > or the field ‘pos’ of record ‘P_ViewSegment’, > > > > > > defined at > > > > > > > > /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:1129:5 > > > > > > or the field ‘pos’ of record ‘P_ViewD’, > > > > > > defined at > > > > > > > > /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:1080:5 > > > > > > or the field ‘pos’ of record ‘P_IdentDf’, > > > > > > defined at > > > > > > > > /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:1024:5 > > > > > > or the field ‘pos’ of record ‘P_BoxItem’, > > > > > > defined at > > > > > > > > /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:981:9 > > > > > > or the field ‘pos’ of record ‘TemplateKeyValue’, > > > > > > defined at > > > > > > > > /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:959:5 > > > > > > or the field ‘pos’ of record ‘BoxHeader’, > > > > > > defined at > > > > > > > > /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:947:5 > > > > > > or the field ‘pos’ of record ‘P_SubIfc’, > > > > > > defined at > > > > > > > > /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:934:9 > > > > > > or the field ‘pos’ of record ‘P_Interface’, > > > > > > defined at > > > > > > > > /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:899:5 > > > > > > or the field ‘pos’ of record ‘P_Population’, > > > > > > defined at > > > > > > > > /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:870:9 > > > > > > or the field ‘pos’ of record ‘P_Rule’, > > > > > > defined at > > > > > > > > /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:806:5 > > > > > > or the field ‘pos’ of record ‘PairViewSegment’, > > > > > > defined at > > > > > > > > /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:740:9 > > > > > > or the field ‘pos’ of record ‘P_NamedRel’, > > > > > > defined at > > > > > > > > /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:591:5 > > > > > > or the field ‘pos’ of record ‘PAtomPair’, > > > > > > defined at > > > > > > > > /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:467:5 > > > > > > or the field ‘pos’ of record ‘Pragma’, > > > > > > defined at > > > > > > > > /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:415:5 > > > > > > or the field ‘pos’ of record ‘P_Relation’, > > > > > > defined at > > > > > > > > /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:408:5 > > > > > > or the field ‘pos’ of record ‘Representation’, > > > > > > defined at > > > > > > > > /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:339:5 > > > > > > or the field ‘pos’ of record ‘PConceptDef’, > > > > > > defined at > > > > > > > > /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:268:5 > > > > > > or the field ‘pos’ of record ‘P_Pattern’, > > > > > > defined at > > > > > > > > /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:209:5 > > > > > > or the field ‘pos’ of record ‘Role’, > > > > > > defined at > > > > > > > > /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:185:5 > > > > > > or the field ‘pos’ of record ‘P_RoleRule’, > > > > > > defined at > > > > > > > > /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:172:5 > > > > > > or the field ‘pos’ of record ‘P_Enforce’, > > > > > > defined at > > > > > > > > /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:152:5 > > > > > > or the field ‘pos’ of record ‘MetaData’, > > > > > > defined at > > > > > > > > /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:136:5 > > > > > > > > > > > > Previously, it was totally fine to have different data types each > > have a > > > > > > field with the same name, as long as you used > > `DuplicateRecordFields` > > > > > > > > > > > > I have searched the migration documentation but I couldn't find > > any clue > > > > > on > > > > > > why this has been changed or how to deal with it. I probably > > missed it. > > > > > > Any help is mostly appreciated! > > > > > > > > > > > > Thanks for reading > > > > > > Cheers, > > > > > > Han Joosten > > > > > > > > > > > _______________________________________________ > > > > > > 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. > > > > > > > _______________________________________________ > > > > 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. > > _______________________________________________ > > 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 folsk0pratima at cock.li Sun Apr 14 19:47:04 2024 From: folsk0pratima at cock.li (Folsk Pratima) Date: Sun, 14 Apr 2024 19:47:04 -0000 Subject: [Haskell-cafe] runST $ unsafeIOToST $ ioWhatever Message-ID: <20240414194704.3e2b1d31@folsk0pratima.cock.li> How wrong is it exactly? Did not get a reply on beginners at haskell.org import Control.Exception import Control.Monad.ST import Control.Monad.ST.Unsafe import Data.Word import Foreign.C.String import Foreign.C.String import Foreign.C.Types import Foreign.Marshal import Foreign.Ptr import Foreign.Storable foreign import ccall unsafe "strerror_r_portalbe.c strerror_r_portable" c_strerror_r :: CInt -> Ptr CChar -> CSize -> IO CInt memSet :: Ptr a -> Word8 -> Word32 -> IO (Ptr a) memSet ptr _ 0 = return ptr memSet ptr byte size = do let voidptr = castPtr ptr :: Ptr Word8 acts = map (\i -> pokeByteOff voidptr i byte) [0 .. fromIntegral (size - 1)] mapM_ id acts return ptr strError :: Int -> String strError errnum = runST $ unsafeIOToST ioString where baseSize :: CSize baseSize = 50 ioString = run baseSize run :: CSize -> IO String run size | size > 100000 = throwIO $ userError $ "!!! INTERNAL strError memory leak detected, " ++ "you can not recover !!!" | otherwise = do may <- tryIOString size case may of Just str -> return str Nothing -> run (size + baseSize) tryIOString :: CSize -> IO (Maybe String) tryIOString size = allocaBytes (fromIntegral size) $ \ptr -> do zeroptr <- memSet ptr 0 (fromIntegral size) st <- c_strerror_r (fromIntegral errnum) ptr size -- heuristic case st of 22 -> return . return $ "Unknown error " ++ show errnum 34 -> return Nothing _ -> peekCAString ptr >>= return . return main = mapM_ (putStrLn) $ map strError [1 .. 1000] The C file is #define _POSIX_C_SOURCE 200112L #include int strerror_r (int, char *, size_t); int strerror_r_portable (int e, char *c, size_t s) { return strerror_r (e, c, s); } By default GHC picks up GNU version of strerror_r(), I want to pick up the default portable version. I do not know how to make GHC understand my desires. From lemming at henning-thielemann.de Sun Apr 14 19:56:16 2024 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Sun, 14 Apr 2024 21:56:16 +0200 (CEST) Subject: [Haskell-cafe] runST $ unsafeIOToST $ ioWhatever In-Reply-To: <20240414194704.3e2b1d31@folsk0pratima.cock.li> References: <20240414194704.3e2b1d31@folsk0pratima.cock.li> Message-ID: <3abf3a1a-a628-8166-7f5c-cab1b4d8e30@henning-thielemann.de> On Sun, 14 Apr 2024, Folsk Pratima wrote: > strError :: Int -> String > strError errnum = runST $ unsafeIOToST ioString Instead of (runST $ unsafeIOToST ioString) you could just call (unsafePerformIO ioString). However, ioString must not have observable side effects. throwIO does not look right and should be 'error'. From lemming at henning-thielemann.de Sun Apr 14 20:03:17 2024 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Sun, 14 Apr 2024 22:03:17 +0200 (CEST) Subject: [Haskell-cafe] runST $ unsafeIOToST $ ioWhatever In-Reply-To: <20240414194704.3e2b1d31@folsk0pratima.cock.li> References: <20240414194704.3e2b1d31@folsk0pratima.cock.li> Message-ID: <34c31cd2-ffe7-fa75-705c-5a0e61637ef@henning-thielemann.de> On Sun, 14 Apr 2024, Folsk Pratima wrote: > memSet :: Ptr a -> Word8 -> Word32 -> IO (Ptr a) > memSet ptr _ 0 = return ptr > memSet ptr byte size = do > let voidptr = castPtr ptr :: Ptr Word8 > acts = > map > (\i -> pokeByteOff voidptr i byte) > [0 .. fromIntegral (size - 1)] > mapM_ id acts > return ptr I think you just want pokeArray ptr $ replicate (fromIntegral size) byte From lemming at henning-thielemann.de Sun Apr 14 20:16:57 2024 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Sun, 14 Apr 2024 22:16:57 +0200 (CEST) Subject: [Haskell-cafe] runST $ unsafeIOToST $ ioWhatever In-Reply-To: <20240414194704.3e2b1d31@folsk0pratima.cock.li> References: <20240414194704.3e2b1d31@folsk0pratima.cock.li> Message-ID: On Sun, 14 Apr 2024, Folsk Pratima wrote: > tryIOString :: CSize -> IO (Maybe String) > tryIOString size = > allocaBytes (fromIntegral size) $ \ptr -> do > zeroptr <- memSet ptr 0 (fromIntegral size) You may instead do withArray (replicate (fromIntegral size) 0) $ \ptr -> do st <- c_strerror_r (fromIntegral errnum) ptr size ... From ben at well-typed.com Mon Apr 15 19:46:27 2024 From: ben at well-typed.com (Ben Gamari) Date: Mon, 15 Apr 2024 15:46:27 -0400 Subject: [Haskell-cafe] [ANNOUNCE] GHC 9.10.1-alpha3 is now available Message-ID: <87jzkye7e4.fsf@smart-cactus.org> The GHC developers are very pleased to announce the availability of the third alpha release of GHC 9.10.1. Binary distributions, source distributions, and documentation are available at https://downloads.haskell.org/ghc/9.10.1-alpha3 We hope to have this release available via ghcup shortly. GHC 9.10 will bring a number of new features and improvements, including: * The introduction of the `GHC2024` language edition, building upon `GHC2021` with the addition of a number of widely-used extensions. * Partial implementation of the [GHC Proposal #281], allowing visible quantification to be used in the types of terms. * [Extension] of LinearTypes to allow linear `let` and `where` bindings ([linear let]) * The implementation of the [exception backtrace proposal], allowing the annotation of exceptions with backtraces, as well as other user-defined context * Further improvements in the info table provenance mechanism, reducing code size to allow IPE information to be enabled more widely * Javascript FFI support in the WebAssembly backend * Improvements in the fragmentation characteristics of the low-latency non-moving garbage collector. * ... and many more A full accounting of changes can be found in the [release notes]. As always, GHC's release status, including planned future releases, can be found on the GHC Wiki [status]. This alpha is the penultimate prerelease leading to 9.10.1. In two weeks we plan to publish a release candidate, followed, if all things go well, by the final release a week later. We would like to thank GitHub, IOG, the Zw3rk stake pool, Well-Typed, Tweag I/O, Serokell, Equinix, SimSpace, the Haskell Foundation, and other anonymous contributors whose on-going financial and in-kind support has facilitated GHC maintenance and release management over the years. Finally, this release would not have been possible without the hundreds of open-source contributors whose work comprise this release. As always, do give this release a try and open a [ticket] if you see anything amiss. Cheers, ~ Ben [release notes]: https://downloads.haskell.org/ghc/9.10.1-alpha3/docs/users_guide/9.10.1-notes.html [status]: https://gitlab.haskell.org/ghc/ghc/-/wikis/GHC-status [exception backtrace]: https://github.com/ghc-proposals/ghc-proposals/pull/330 [GHC Proposal #281]: https://github.com/ghc-proposals/ghc-proposals/pull/281 [linear let]: https://github.com/ghc-proposals/ghc-proposals/pull/624 [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From zubin at well-typed.com Tue Apr 16 06:41:51 2024 From: zubin at well-typed.com (Zubin Duggal) Date: Tue, 16 Apr 2024 12:11:51 +0530 Subject: [Haskell-cafe] [ANNOUNCE] GHC 9.6.5 is now available Message-ID: The GHC developers are happy to announce the availability of GHC 9.6.5. Binary distributions, source distributions, and documentation are available on the [release page](https://www.haskell.org/ghc/download_ghc_9_6_5.html). GHC Blog Post: https://www.haskell.org/ghc/blog/20240416-ghc-9.6.5-released.html This release is primarily a bugfix release addressing some issues found in the 9.6 series. These include: * Bumping the bundled `process` library to 1.6.19.0 to avoid a potential [command injection vulnerability] on Windows for clients of this library. This isn't known to affect GHC itself, but allows users who depend on the installed version of the `process` to avoid the issue. * Fixing a bug resulting in the distributed ``hsc2hs`` wrapper using flags from the compiler build environment (#24050). * Disabling the `-fasm-shortcutting` optimisation with `-O2` as it is known to result in unsoundess and incorrect runtime results in some cases (#24507). * Ensuring we take ``LDFLAGS`` into account when configuring a linker (#24565). * Fixing a bug arising from incorrect parsing of paths containing spaces in the settings file (#24265). * And many more fixes A full accounting of changes can be found in the [release notes]. As some of the fixed issues do affect correctness users are encouraged to upgrade promptly. We would like to thank Microsoft Azure, GitHub, IOG, the Zw3rk stake pool, Well-Typed, Tweag I/O, Serokell, Equinix, SimSpace, Haskell Foundation, and other anonymous contributors whose on-going financial and in-kind support has facilitated GHC maintenance and release management over the years. Finally, this release would not have been possible without the hundreds of open-source contributors whose work comprise this release. As always, do give this release a try and open a [ticket][] if you see anything amiss. Enjoy! -Zubin [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new [release notes]: https://downloads.haskell.org/~ghc/9.6.5/docs/users_guide/9.6.5-notes.html [command injection vulnerability]: https://github.com/haskell/security-advisories/blob/main/advisories/hackage/process/HSEC-2024-0003.md -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: not available URL: From folsk0pratima at cock.li Tue Apr 16 10:49:00 2024 From: folsk0pratima at cock.li (Folsk Pratima) Date: Tue, 16 Apr 2024 10:49:00 -0000 Subject: [Haskell-cafe] Teach me to cooperate with IOException Message-ID: <20240416104139.6256763a@folsk0pratima.cock.li> Consider following C code. ``` int syscall_that_fails (int *errno_here) { *errno_here = 2; return -1; } ``` Now I write the haskell wrapper, first without any error checking. ``` module Complex where import Foreign import Foreign.C import Foreign.C.Types import Foreign.Storable foreign import ccall unsafe "complex.c syscall_that_fails" c_syscall_that_fails :: Ptr CInt -> IO CInt sysCall :: Int -> IO () sysCall i = allocaBytes (sizeOf (0 :: CInt)) $ \ptr -> c_syscall_that_fails ptr >> return () ``` Now I want to introduce some actual error checking, so at first I simply do ``` module Complex where import Control.Exception import Foreign import Foreign.C import Foreign.C.Types import Foreign.Storable foreign import ccall unsafe "complex.c syscall_that_fails" c_syscall_that_fails :: Ptr CInt -> IO CInt sysCall :: Int -> IO () sysCall i = allocaBytes (sizeOf (0 :: CInt)) $ \ptr -> do st <- c_syscall_that_fails ptr errno <- peekElemOff ptr 0 case st of (-1) -> throwIO $ userError $ "syscall: " ++ show errno _ -> return () ``` Now, I do not think it is a "user error", it is a real system call error that might or might not be already covered by System.IO.Error. In my case errno is 2, it is "No such file or directory", so it is covered by System.IO.Error and I may just use the library. But my C code may call whatever! What if System.IO does not cover that range of `errno`s? What if I want to distinguish between *my* errors and system errors? In such case I have to introduce my own way to do it. How do I do it? My first wild guess is to introduce my own exception, like this. ``` module Complex where import Control.Exception import Foreign import Foreign.C import Foreign.C.Types import Foreign.Storable data CException = LocalCallFailed { cexeption_errno :: Int , cexception_caller :: String } instance Show CException where show (LocalCallFailed errno caller) = caller ++ ": " ++ show errno instance Exception CException foreign import ccall unsafe "complex.c syscall_that_fails" c_syscall_that_fails :: Ptr CInt -> IO CInt sysCall :: Int -> IO () sysCall i = allocaBytes (sizeOf (0 :: CInt)) $ \ptr -> do st <- c_syscall_that_fails ptr errno <- peekElemOff ptr 0 case st of (-1) -> throwIO . LocalCallFailed (fromIntegral errno) $ "syscall" _ -> return () ``` And now I ask myself, what if allocaBytes fails? I looked on its code and it does ioError, thus, it will throwIO. If then I need to invoke sysCall, I can not use `try` anymore, because it is not determined what I will catch, LocalCallFailed or IOException. Next, what if I extend the `case of` clause to include some other errors, that are not related to system calls, but are my own? I try to recover, but can not come up with anything better than this... ``` module Complex where import Control.Exception import Foreign import Foreign.C import Foreign.C.Types import Foreign.Storable data CException = LocalCallFailed { cexeption_errno :: Int , cexception_caller :: String } | GenericIOException { genericioexception :: IOException } instance Show CException where show (LocalCallFailed errno caller) = caller ++ ": " ++ show errno show (GenericIOException e) = displayException e instance Exception CException ioExceptionToMe :: IO (Either IOException a) -> IO a ioExceptionToMe action = do e0 <- action case e0 of Left e -> throwIO . GenericIOException $ e Right a -> return a tryIO :: IO a -> IO a tryIO action = ioExceptionToMe $ try action foreign import ccall unsafe "complex.c syscall_that_fails" c_syscall_that_fails :: Ptr CInt -> IO CInt sysCall :: Int -> IO () sysCall i = tryIO $ allocaBytes (sizeOf (0 :: CInt)) $ \ptr -> do st <- c_syscall_that_fails ptr errno <- tryIO $ peekElemOff ptr 0 case st of (-1) -> throwIO . LocalCallFailed (fromIntegral errno) $ "syscall" _ -> return () ``` Now, this seems to be easily extendable. I can change LocalCallFailed to LocalSyscallFailed and then add something like LocalOwnFailed, which would account for some C error that is not attributed to system calls, and so on. But still, it seems very dumb, because of how I use tryIO. I have to use it on literally every haskell provided IO and... It just does not seem right. From lemming at henning-thielemann.de Tue Apr 16 10:58:13 2024 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Tue, 16 Apr 2024 12:58:13 +0200 (CEST) Subject: [Haskell-cafe] Teach me to cooperate with IOException In-Reply-To: <20240416104139.6256763a@folsk0pratima.cock.li> References: <20240416104139.6256763a@folsk0pratima.cock.li> Message-ID: <77bd8e5-4b16-bb79-1cd-53e3e9cbb71@henning-thielemann.de> On Tue, 16 Apr 2024, Folsk Pratima wrote: > foreign import ccall unsafe "complex.c syscall_that_fails" c_syscall_that_fails > :: Ptr CInt -> IO CInt > > sysCall :: Int -> IO () > sysCall i = > allocaBytes (sizeOf (0 :: CInt)) $ \ptr -> do > st <- c_syscall_that_fails ptr > errno <- peekElemOff ptr 0 > case st of > (-1) -> throwIO $ userError $ "syscall: " ++ show errno > _ -> return () > > ``` > > Now, I do not think it is a "user error", it is a real system call > error that might or might not be already covered by System.IO.Error. In > my case errno is 2, it is "No such file or directory", so it is covered > by System.IO.Error and I may just use the library. But my C code may > call whatever! Generally I discourage using the exceptions implicit in IO. Exceptions must be properly handled by the function caller, the caller must know what exceptions can occur. Thus I prefer using Exception monad transformers like transformers:Trans.ExceptT or explicit-exception:Trans.Exception.Synchronous. From george.colpitts at gmail.com Tue Apr 16 13:51:23 2024 From: george.colpitts at gmail.com (George Colpitts) Date: Tue, 16 Apr 2024 10:51:23 -0300 Subject: [Haskell-cafe] ghc should be able to deduce correct use of partial functions and not give a warning in such cases Message-ID: ghc should be able to deduce correct use of partial functions and not give a warning in such cases, e.g. in 9.8.2 if null ys then [] else [(xs,tail ys)]) gets a warning warning: [GHC-63394] [-Wx-partial] but it is clear that this use of tail will never be a problem so IMHO that line of code should not get a warning. Does anybody know if there is a plan or enhancement request to eliminate such warnings? Cheers George -------------- next part -------------- An HTML attachment was scrubbed... URL: From lemming at henning-thielemann.de Tue Apr 16 14:46:15 2024 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Tue, 16 Apr 2024 16:46:15 +0200 (CEST) Subject: [Haskell-cafe] ghc should be able to deduce correct use of partial functions and not give a warning in such cases In-Reply-To: References: Message-ID: On Tue, 16 Apr 2024, George Colpitts wrote: > ghc should be able to deduce correct use of partial functions and not give a warning in such cases, e.g. > in 9.8.2 > >      if null ys then [] else [(xs,tail ys)]) > > gets a warning > >       warning: [GHC-63394] [-Wx-partial] > > but it is clear that this use of tail will never be a problem so IMHO that line of code should not get a > warning.  > > Does anybody know if there is a plan or enhancement request to eliminate such warnings?  I would just use good old pattern matching: case ys of [] -> [] _:zs -> [(xs,zs)] From mmcconnell17704 at yahoo.com Tue Apr 16 14:56:55 2024 From: mmcconnell17704 at yahoo.com (Mark McConnell) Date: Tue, 16 Apr 2024 14:56:55 +0000 (UTC) Subject: [Haskell-cafe] ghc should be able to deduce correct use of partial functions and not give a warning in such cases In-Reply-To: References: Message-ID: <1724894765.5953690.1713279415739@mail.yahoo.com> This is what I was going to say.  The original poster is right, but still, null is a function.  It is one level of indirection away from pattern matching. On Tuesday, April 16, 2024 at 10:46:56 AM EDT, Henning Thielemann wrote: On Tue, 16 Apr 2024, George Colpitts wrote: > ghc should be able to deduce correct use of partial functions and not give a warning in such cases, e.g. > in 9.8.2 > >      if null ys then [] else [(xs,tail ys)]) > > gets a warning > >       warning: [GHC-63394] [-Wx-partial] > > but it is clear that this use of tail will never be a problem so IMHO that line of code should not get a > warning.  > > Does anybody know if there is a plan or enhancement request to eliminate such warnings?  I would just use good old pattern matching: case ys of     [] -> []     _:zs -> [(xs,zs)]_______________________________________________ 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 george.colpitts at gmail.com Tue Apr 16 14:57:31 2024 From: george.colpitts at gmail.com (George Colpitts) Date: Tue, 16 Apr 2024 11:57:31 -0300 Subject: [Haskell-cafe] ghc should be able to deduce correct use of partial functions and not give a warning in such cases In-Reply-To: References: Message-ID: Hi Henning, Thanks for the quick response! Yes, that's basically how I fixed it but I really don't want to have to do that since the code is correct. Not a big deal but may be irritating to beginners or large projects that want to eliminate warnings. Do you think an ER would be rejected ? If I remember correctly there is already detection of incomplete pattern matching that is ok and in such cases warnings are omitted. This would be similar to that. Cheers, George On Tue, Apr 16, 2024 at 11:46 AM Henning Thielemann < lemming at henning-thielemann.de> wrote: > > On Tue, 16 Apr 2024, George Colpitts wrote: > > > ghc should be able to deduce correct use of partial functions and not > give a warning in such cases, e.g. > > in 9.8.2 > > > > if null ys then [] else [(xs,tail ys)]) > > > > gets a warning > > > > warning: [GHC-63394] [-Wx-partial] > > > > but it is clear that this use of tail will never be a problem so IMHO > that line of code should not get a > > warning. > > > > Does anybody know if there is a plan or enhancement request to eliminate > such warnings? > > > I would just use good old pattern matching: > > case ys of > [] -> [] > _:zs -> [(xs,zs)] -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivanperezdominguez at gmail.com Tue Apr 16 15:21:17 2024 From: ivanperezdominguez at gmail.com (Ivan Perez) Date: Tue, 16 Apr 2024 08:21:17 -0700 Subject: [Haskell-cafe] ghc should be able to deduce correct use of partial functions and not give a warning in such cases In-Reply-To: References: Message-ID: Wouldn't you have to be able to inline null and tail to be able to say that this use of tail is not partial? If null and tail "live" in a different library, is there much that you can do? Thanks, Ivan On Tue, 16 Apr 2024 at 07:58, George Colpitts wrote: > Hi Henning, > > Thanks for the quick response! > Yes, that's basically how I fixed it but I really don't want to have to do > that since the code is correct. Not a big deal but may be irritating to > beginners or large projects that want to eliminate warnings. Do you think > an ER would be rejected ? If I remember correctly there is already > detection of incomplete pattern matching that is ok and in such cases > warnings are omitted. This would be similar to that. > > Cheers, > George > > > On Tue, Apr 16, 2024 at 11:46 AM Henning Thielemann < > lemming at henning-thielemann.de> wrote: > >> >> On Tue, 16 Apr 2024, George Colpitts wrote: >> >> > ghc should be able to deduce correct use of partial functions and not >> give a warning in such cases, e.g. >> > in 9.8.2 >> > >> > if null ys then [] else [(xs,tail ys)]) >> > >> > gets a warning >> > >> > warning: [GHC-63394] [-Wx-partial] >> > >> > but it is clear that this use of tail will never be a problem so IMHO >> that line of code should not get a >> > warning. >> > >> > Does anybody know if there is a plan or enhancement request to >> eliminate such warnings? >> >> >> I would just use good old pattern matching: >> >> case ys of >> [] -> [] >> _:zs -> [(xs,zs)] > > _______________________________________________ > 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 lemming at henning-thielemann.de Tue Apr 16 15:45:21 2024 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Tue, 16 Apr 2024 17:45:21 +0200 (CEST) Subject: [Haskell-cafe] ghc should be able to deduce correct use of partial functions and not give a warning in such cases In-Reply-To: References: Message-ID: <8ad79d57-c0f9-bc2a-a294-6eb1b532780@henning-thielemann.de> On Tue, 16 Apr 2024, George Colpitts wrote: > Yes, that's basically how I fixed it but I really don't want to have to > do that since the code is correct. Not a big deal but may be irritating > to beginners or large projects that want to eliminate warnings. Do you > think an ER would be rejected ? If I remember correctly there is already > detection of incomplete pattern matching that is ok and in such cases > warnings are omitted. This would be similar to that. To my human linter 'tail' looks always suspicious and needs an additional mental check, that 'tail' is no problem in your special case. The pattern match does not have this problem. It both improves readability and convinces GHC easily. That's what the warning shall achieve and it is even a good guide to beginners. From george.colpitts at gmail.com Tue Apr 16 15:57:48 2024 From: george.colpitts at gmail.com (George Colpitts) Date: Tue, 16 Apr 2024 12:57:48 -0300 Subject: [Haskell-cafe] ghc should be able to deduce correct use of partial functions and not give a warning in such cases In-Reply-To: <8ad79d57-c0f9-bc2a-a294-6eb1b532780@henning-thielemann.de> References: <8ad79d57-c0f9-bc2a-a294-6eb1b532780@henning-thielemann.de> Message-ID: Makes sense ! On Tue, Apr 16, 2024 at 12:45 PM Henning Thielemann < lemming at henning-thielemann.de> wrote: > > On Tue, 16 Apr 2024, George Colpitts wrote: > > > Yes, that's basically how I fixed it but I really don't want to have to > > do that since the code is correct. Not a big deal but may be irritating > > to beginners or large projects that want to eliminate warnings. Do you > > think an ER would be rejected ? If I remember correctly there is already > > detection of incomplete pattern matching that is ok and in such cases > > warnings are omitted. This would be similar to that. > > To my human linter 'tail' looks always suspicious and needs an additional > mental check, that 'tail' is no problem in your special case. The pattern > match does not have this problem. It both improves readability and > convinces GHC easily. That's what the warning shall achieve and it is even > a good guide to beginners. -------------- next part -------------- An HTML attachment was scrubbed... URL: From frederic-emmanuel.picca at synchrotron-soleil.fr Wed Apr 17 08:07:35 2024 From: frederic-emmanuel.picca at synchrotron-soleil.fr (PICCA Frederic-Emmanuel) Date: Wed, 17 Apr 2024 10:07:35 +0200 (CEST) Subject: [Haskell-cafe] how to integrate a build in automake Message-ID: <1013556727.5156229.1713341255235.JavaMail.zimbra@synchrotron-soleil.fr> Hello, I am trying to build a program with the autotools. At the end I need to link this program with a few libraries with libtool. I wrote something like this but ghc (on Debian stable) does not deal with the default LDFLAGS of the distribution. So I need to generate only the .o files and do the final link by myself. Do you have examples of Makefile.am for an haskell program. Here the current autotool file which I need to modify in order to do the final link... https://repo.or.cz/hkl.git/blob/c2359440baeb38f5acbee91507d1aacf36f1b5bb:/binoculars-ng/Makefile.am thanks for your help. Frederic From olf at aatal-apotheke.de Thu Apr 18 07:39:16 2024 From: olf at aatal-apotheke.de (Olaf Klinke) Date: Thu, 18 Apr 2024 09:39:16 +0200 Subject: [Haskell-cafe] ghc should be able to deduce correct use of partial functions and not give a warning in such cases Message-ID: > ghc should be able to deduce correct use of partial functions and not > give > a warning in such cases, e.g. in 9.8.2 > > if null ys then [] else [(xs,tail ys)]) > > gets a warning > > warning: [GHC-63394] [-Wx-partial] > > but it is clear that this use of tail will never be a problem so IMHO > that > line of code should not get a warning. > > Does anybody know if there is a plan or enhancement request to > eliminate > such warnings? > > Cheers > George The problem is that both partiality checks and checks for incomplete pattern matches are undecidable in general, that is, without assistance the compiler can not infer partiality without risking infinite loops. Checks for incomplete pattern matches could be decidable, if it was not for view patterns, where you can hide arbitrary function applications (think unsafePerformIO) in. Currently GHC plays the safe card, see this thread: https://mail.haskell.org/pipermail/haskell-cafe/2024-January/136545.html With the help of special annotation such as Liquid Haskell you might be able to teach the compiler that your use of partial functions is fine. https://ucsd-progsys.github.io/liquidhaskell/ However, I second Henning in that a -Wx-partial warning hints at the necessity of a code re-factoring. Olaf From george.colpitts at gmail.com Thu Apr 18 22:23:34 2024 From: george.colpitts at gmail.com (George Colpitts) Date: Thu, 18 Apr 2024 19:23:34 -0300 Subject: [Haskell-cafe] ghc should be able to deduce correct use of partial functions and not give a warning in such cases In-Reply-To: References: Message-ID: It seems that I can replace if null ys then [] else [(xs,tail ys)]) with if null ys then [] else [(xs, Safe.tailErr ys)]) and not get any warnings so I think I am going to do that. I'm surprised that the warning doesn't mention that option to fix the issue. Do you see any issues with this fix? Thanks, George On Tue, Apr 16, 2024 at 11:57 AM George Colpitts wrote: > Hi Henning, > > Thanks for the quick response! > Yes, that's basically how I fixed it but I really don't want to have to do > that since the code is correct. Not a big deal but may be irritating to > beginners or large projects that want to eliminate warnings. Do you think > an ER would be rejected ? If I remember correctly there is already > detection of incomplete pattern matching that is ok and in such cases > warnings are omitted. This would be similar to that. > > Cheers, > George > > > On Tue, Apr 16, 2024 at 11:46 AM Henning Thielemann < > lemming at henning-thielemann.de> wrote: > >> >> On Tue, 16 Apr 2024, George Colpitts wrote: >> >> > ghc should be able to deduce correct use of partial functions and not >> give a warning in such cases, e.g. >> > in 9.8.2 >> > >> > if null ys then [] else [(xs,tail ys)]) >> > >> > gets a warning >> > >> > warning: [GHC-63394] [-Wx-partial] >> > >> > but it is clear that this use of tail will never be a problem so IMHO >> that line of code should not get a >> > warning. >> > >> > Does anybody know if there is a plan or enhancement request to >> eliminate such warnings? >> >> >> I would just use good old pattern matching: >> >> case ys of >> [] -> [] >> _:zs -> [(xs,zs)] > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon at joyful.com Fri Apr 19 00:52:18 2024 From: simon at joyful.com (Simon Michael) Date: Thu, 18 Apr 2024 14:52:18 -1000 Subject: [Haskell-cafe] ANN: hledger 1.33 Message-ID: <001e0568-f1c5-4fc5-bb49-87de2302d247@app.fastmail.com> Hi all, I'm pleased to announce hledger 1.33! This release comes a bit later than usual, with help from contributors Jonathan Dowland, Ilja Kocken, Colin Dean, Dmitry Astapov, Vekhir, ShrykeWindgrace, Martijn van der Ven, Michael Rees, aragaer, and hamzashezad. Highlights: `close` enhancements, hledger-ui 'dark' theme, GHC 9.8 support, Apple ARM binaries, and the usual improvements and fixes. - https://github.com/simonmichael/hledger/releases/1.33 - https://hledger.org/relnotes.html#2024-04-18-hledger-133 - https://hledger.org/install Wishing you peace and prosperity, -Simon What is hledger ? Fast, reliable, free, multicurrency, double-entry, plain text accounting software for unix, mac, windows, and the web; built around human-readable, version-controllable plain text files; inspired by and largely compatible with Ledger CLI; convertible to and from Beancount; written in Haskell for reliability and longevity. For help getting started or more info, see https://hledger.org and join our Matrix/IRC chat or mail list: https://hledger.org/support . Newcomers, experts, contributors, sponsors, feedback are welcome! For more about plain text accounting, see https://plaintextaccounting.org . -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Fri Apr 19 01:03:28 2024 From: allbery.b at gmail.com (Brandon Allbery) Date: Thu, 18 Apr 2024 21:03:28 -0400 Subject: [Haskell-cafe] ANN: hledger 1.33 In-Reply-To: <001e0568-f1c5-4fc5-bb49-87de2302d247@app.fastmail.com> References: <001e0568-f1c5-4fc5-bb49-87de2302d247@app.fastmail.com> Message-ID: On Thu, Apr 18, 2024 at 8:53 PM Simon Michael wrote: > - https://hledger.org/relnotes.html#2024-04-18-hledger-133 > > The displayed link is correct, but if you click on it it sends you to https://hledger.org/rel.html#2024-04-18-hledger-133 (note absence of "notes") which 404s. -- brandon s allbery kf8nh allbery.b at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From mmcconnell17704 at yahoo.com Fri Apr 19 02:01:43 2024 From: mmcconnell17704 at yahoo.com (Mark McConnell) Date: Fri, 19 Apr 2024 02:01:43 +0000 (UTC) Subject: [Haskell-cafe] ghc should be able to deduce correct use of partial functions and not give a warning in such cases In-Reply-To: References: Message-ID: <1762326044.591885.1713492103994@mail.yahoo.com> Is pattern matching more elegant than Safe.tailErr ?  Pattern matching makes your meaning visible to the eye. On Thursday, April 18, 2024 at 06:24:29 PM EDT, George Colpitts wrote: It seems that I can replace   if null ys then [] else [(xs,tail ys)]) with  if null ys then [] else [(xs, Safe.tailErr ys)]) and not get any warnings so I think I am going to do that. I'm surprised that the warning doesn't mention that option to fix the issue. Do you see any issues with this fix? Thanks,George On Tue, Apr 16, 2024 at 11:57 AM George Colpitts wrote: Hi Henning, Thanks for the quick response!Yes, that's basically how I fixed it but I really don't want to have to do that since the code is correct. Not a big deal but may be irritating to beginners or large projects that want to eliminate warnings. Do you think an ER would be rejected ? If I remember correctly there is already detection of incomplete pattern matching that is ok and in such cases warnings are omitted. This would be similar to that. Cheers,George On Tue, Apr 16, 2024 at 11:46 AM Henning Thielemann wrote: On Tue, 16 Apr 2024, George Colpitts wrote: > ghc should be able to deduce correct use of partial functions and not give a warning in such cases, e.g. > in 9.8.2 > >      if null ys then [] else [(xs,tail ys)]) > > gets a warning > >       warning: [GHC-63394] [-Wx-partial] > > but it is clear that this use of tail will never be a problem so IMHO that line of code should not get a > warning.  > > Does anybody know if there is a plan or enhancement request to eliminate such warnings?  I would just use good old pattern matching: case ys of     [] -> []     _:zs -> [(xs,zs)] _______________________________________________ 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 raoknz at gmail.com Fri Apr 19 03:33:38 2024 From: raoknz at gmail.com (Richard O'Keefe) Date: Fri, 19 Apr 2024 15:33:38 +1200 Subject: [Haskell-cafe] ghc should be able to deduce correct use of partial functions and not give a warning in such cases In-Reply-To: References: Message-ID: I do see a problem with the use of Safe.tailErr in this example and that is that it turns something that could be simple and obvious into something quite obscure. On Fri, 19 Apr 2024 at 10:24, George Colpitts wrote: > > It seems that I can replace > > if null ys then [] else [(xs,tail ys)]) > > with > > if null ys then [] else [(xs, Safe.tailErr ys)]) > > > and not get any warnings so I think I am going to do that. I'm surprised that the warning doesn't mention that option to fix the issue. Do you see any issues with this fix? > > Thanks, > George > > > On Tue, Apr 16, 2024 at 11:57 AM George Colpitts wrote: >> >> Hi Henning, >> >> Thanks for the quick response! >> Yes, that's basically how I fixed it but I really don't want to have to do that since the code is correct. Not a big deal but may be irritating to beginners or large projects that want to eliminate warnings. Do you think an ER would be rejected ? If I remember correctly there is already detection of incomplete pattern matching that is ok and in such cases warnings are omitted. This would be similar to that. >> >> Cheers, >> George >> >> >> On Tue, Apr 16, 2024 at 11:46 AM Henning Thielemann wrote: >>> >>> >>> On Tue, 16 Apr 2024, George Colpitts wrote: >>> >>> > ghc should be able to deduce correct use of partial functions and not give a warning in such cases, e.g. >>> > in 9.8.2 >>> > >>> > if null ys then [] else [(xs,tail ys)]) >>> > >>> > gets a warning >>> > >>> > warning: [GHC-63394] [-Wx-partial] >>> > >>> > but it is clear that this use of tail will never be a problem so IMHO that line of code should not get a >>> > warning. >>> > >>> > Does anybody know if there is a plan or enhancement request to eliminate such warnings? >>> >>> >>> I would just use good old pattern matching: >>> >>> case ys of >>> [] -> [] >>> _:zs -> [(xs,zs)] > > _______________________________________________ > 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 newsletters at istaletan.com Fri Apr 19 03:44:44 2024 From: newsletters at istaletan.com (Ben) Date: Fri, 19 Apr 2024 05:44:44 +0200 (CEST) Subject: [Haskell-cafe] ghc should be able to deduce correct use of partial functions and not give a warning in such cases In-Reply-To: References: Message-ID: I'm not 100% sure what Safe.tailErr function you are using (Hoogle only finds tailErr :: e -> [a] -> Either e [a] ,  which doesn't appear compatible with the way you're using it since it takes an "error message" as first argument). But regardless, any sort of tail function (whether "safe" or not) is going to have to work by pattern matching on the list again. null is a perfectly ordinary function that pattern matches on a list to decide whether to return True or False, and the if/then/else syntax is also essentially just special-purpose syntax for pattern matching a Bool. So your code is essentially pattern matching on a list to decide whether it's empty or not, throwing away the result of that and keeping a Bool instead, then pattern matching on the Bool to split between two cases, then pattern matching on the list again. If you had kept the result of the first pattern match there would be no need for the latter two. Essentially the problem is "boolean blindness" (if you search online you'll find a number of articles elaborating on the concept). All being inside the else branch inherently tells you is that a Bool was False. It doesn't tell you that the list is non-empty, and so it's safe to apply tail. To know that additional information you (either the human code reader or the compiler) have to keep track of additional facts about where the Bool came from (and already know or be able to look inside the definitions of null and tail). In this trivial example this is easy work for a human, and in principle feasible for the compiler to keep track of, but it's still work. So False just isn't a very good way to encode the information "a list is non-empty". If you instead use pattern matching, you get: case ys of   [] -> []   (y:ysTail) -> [(xs, ysTail)] Here the evidence you get out of your check when the list is non-empty isn't just a featureless False, you get evidence that the list is non-empty (and therefore has a head and a tail) by actually getting access to the head and tail. Neither you nor the compiler has to remember that False means the list isn't empty and so it's safe to extract the tail; you just have the tail! This style of coding is generally more readable, maintainable, and less error-prone. So much so that I would opine that the compiler maintainers should specifically avoid making the compiler keep track of the provenance of Bools used in if conditions so it can suppress partiality warnings. Needing to suppress partiality warnings is usually itself a warning sign; often (not always, but often) it's an indicator that you're using simple checks where using richer evidence would work better. If you're a Haskell programmer, you should be comfortable with pattern matching as the primary tool for switching between code branches, rather than test and if, so warnings that nudge beginners away from if null as a pattern are a good thing. (In principle the if+null+tail pattern you're using is less efficient, too. It makes 2 function calls and 3 pattern matches, where a single pattern match would suffice. I mention this later as I think the logic issues of the code are more important, and it's unlikely to be a major issue in practice; the compiler will probably inline and optimise away the extra function calls and pattern matches anyway. But it is another reason to prefer carrying the information you need from the place you checked it, rather than looking into a structure to check that what you need is present and then later looking into the structure again to actually extract what you need. In more complex cases it could be a genuine efficiency concern.) Cheers, Ben 18 Apr 2024, 10:24 pm by george.colpitts at gmail.com: > It seems that I can replace  > > >>  if null ys then [] else [(xs,tail ys)]) >> >> > with  > > >> if null ys then [] else [(xs, Safe.tailErr ys)]) >> > > and not get any warnings so I think I am going to do that. I'm surprised that the warning doesn't mention that option to fix the issue. Do you see any issues with this fix? > > Thanks, > George > > > On Tue, Apr 16, 2024 at 11:57 AM George Colpitts <> george.colpitts at gmail.com> > wrote: > >> Hi Henning, >> >> Thanks for the quick response! >> Yes, that's basically how I fixed it but I really don't want to have to do that since the code is correct. Not a big deal but may be irritating to beginners or large projects that want to eliminate warnings. Do you think an ER would be rejected ? If I remember correctly there is already detection of incomplete pattern matching that is ok and in such cases warnings are omitted. This would be similar to that. >> >> Cheers, >> George >> >> >> On Tue, Apr 16, 2024 at 11:46 AM Henning Thielemann <>> lemming at henning-thielemann.de>> > wrote: >> >>> >>> On Tue, 16 Apr 2024, George Colpitts wrote: >>> >>> > ghc should be able to deduce correct use of partial functions and not give a warning in such cases, e.g. >>> > in 9.8.2 >>> > >>> >      if null ys then [] else [(xs,tail ys)]) >>> > >>> > gets a warning >>> > >>> >       warning: [GHC-63394] [-Wx-partial] >>> > >>> > but it is clear that this use of tail will never be a problem so IMHO that line of code should not get a >>> > warning.  >>> > >>> > Does anybody know if there is a plan or enhancement request to eliminate such warnings?  >>> >>> >>> I would just use good old pattern matching: >>> >>> case ys of >>>     [] -> [] >>>     _:zs -> [(xs,zs)] >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From lemming at henning-thielemann.de Fri Apr 19 07:07:06 2024 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Fri, 19 Apr 2024 09:07:06 +0200 (CEST) Subject: [Haskell-cafe] ghc should be able to deduce correct use of partial functions and not give a warning in such cases In-Reply-To: References: Message-ID: On Fri, 19 Apr 2024, Ben via Haskell-Cafe wrote: > I'm not 100% sure what Safe.tailErr function you are using (Hoogle only > finds tailErr :: e -> [a] -> Either e [a],  which doesn't appear > compatible with the way you're using it since it takes an "error > message" as first argument). I found this one: https://hackage.haskell.org/package/safe-0.3.21/docs/Safe.html#v:tailErr It is problematic in even more ways. First, the reader of the code does not know, which tailErr the programmer means. We must look it up. Even if there would be only one candidate, we must look up what it does. Second, the documentation says, tailErr is meant to suppress the new warning on 'tail' in GHC>=9.8, but is still partial. Not a good idea to suppress a warning that has a purpose. Third, the naming of the 'safe' package and 'Safe' module is misleading, because there is nothing unsafe in 'tail'&Co. in the sense of SafeHaskell or unsafePerformIO. 'tail' is partial, that is, for some inputs it is undefined, read: it may run into an infinite loop. But it will not cause memory corruption or ignite nukes while pretending to stay away from IO. From simon at joyful.com Fri Apr 19 10:42:02 2024 From: simon at joyful.com (Simon Michael) Date: Fri, 19 Apr 2024 00:42:02 -1000 Subject: [Haskell-cafe] ANN: hledger 1.33 In-Reply-To: References: <001e0568-f1c5-4fc5-bb49-87de2302d247@app.fastmail.com> Message-ID: Thanks for that, and here's another error just now resolved: - Fixed hledger-mac-arm64.zip at https://github.com/simonmichael/hledger/releases/tag/1.33 , now it really contains arm binaries On Thu, Apr 18, 2024, at 15:03, Brandon Allbery wrote: > The displayed link is correct, but if you click on it it sends you to https://hledger.org/rel.html#2024-04-18-hledger-133 (note absence of "notes") which 404s. -------------- next part -------------- An HTML attachment was scrubbed... URL: From johannes.waldmann at htwk-leipzig.de Fri Apr 19 11:20:28 2024 From: johannes.waldmann at htwk-leipzig.de (Johannes Waldmann) Date: Fri, 19 Apr 2024 13:20:28 +0200 Subject: [Haskell-cafe] cabal install: Failed to download aeson-2.2.1.0 Message-ID: <285f2575-e6ef-43d6-80bf-42f155918fd6@htwk-leipzig.de> Dear Cafe. "cabal install" sometimes cannot download aeson. This happens repeatedly (in recent days) but it's not fully reproducible. Example where it happens in CI (image haskell-slim) https://git.imn.htwk-leipzig.de/waldmann/pure-matchbox/-/jobs/41533 What might be the reason? - J. From matthewtpickering at gmail.com Fri Apr 19 13:41:32 2024 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Fri, 19 Apr 2024 14:41:32 +0100 Subject: [Haskell-cafe] Call for Talks: Haskell Implementors' Workshop 2024 Message-ID: ``` ACM SIGPLAN Haskell Implementors' Workshop https://icfp24.sigplan.org/home/hiw-2024 Milan, Italy, September 2, 2024 Co-located with ICFP 2024 https://icfp24.sigplan.org/ ``` ## Important dates * Deadline: July 19, 2024 (AoE) * Notification: August 2, 2024 * Workshop: September 2, 2024 The 16th Haskell Implementors’ Workshop is to be held alongside ICFP 2024 this year in Milan. It is a forum for people involved in the design and development of Haskell implementations, tools, libraries, and supporting infrastructure to share their work and to discuss future directions and collaborations with others. Talks and/or demos are proposed by submitting an abstract, and selected by a small program committee. There will be no published proceedings. The workshop will be informal and interactive, with open spaces in the timetable and room for ad-hoc discussion, demos, and lightning talks. ## Scope and Target Audience It is important to distinguish the Haskell Implementors’ Workshop from the Haskell Symposium which is also co-located with ICFP 2024. The Haskell Symposium is for the publication of Haskell-related research. In contrast, the Haskell Implementors’ Workshop will have no proceedings – although we will aim to make talk videos, slides, and presented data available with the consent of the speakers. The Implementors’ Workshop is an ideal place to describe a Haskell extension, describe works-in-progress, demo a new Haskell-related tool, or even propose future lines of Haskell development. Members of the wider Haskell community are encouraged to attend the workshop – we need your feedback to keep the Haskell ecosystem thriving. Students working with Haskell are especially encouraged to share their work. The scope covers any of the following topics. There may be some topics that people feel we’ve missed, so by all means submit a proposal even if it doesn’t fit exactly into one of these buckets: * Compilation techniques * Language features and extensions * Type system implementation * Concurrency and parallelism: language design and implementation * Performance, optimization and benchmarking * Virtual machines and run-time systems * Libraries and tools for development or deployment ## Talks We invite proposals from potential speakers for talks and demonstrations. We are aiming for 20-minute talks with 5 minutes for questions and changeovers. We want to hear from people writing compilers, tools, or libraries, people with cool ideas for directions in which we should take the platform, proposals for new features to be implemented, and half-baked crazy ideas. Please submit a talk title and abstract of no more than 300 words. Submissions can be made via HotCRP at https://hiw2024.hotcrp.com until July 19 (anywhere on earth). We will also have a lightning talks session. These have been very well received in recent years, and we aim to increase the time available to them. Lightning talks should be ~7mins and are scheduled on the day of the workshop. Suggested topics for lightning talks are to present a single idea, a work-in-progress project, a problem to intrigue and perplex Haskell implementors, or simply to ask for feedback and collaborators. ## Program Committee * Matthew Pickering (Well-Typed LLP) * David Binder (University of Tübingen) * Gabriella Gonzalez (Mercury) * Sylvain Henry (IOG) * Teofil Camarasu (Tracsis) ## Contact * Matthew Pickering From frederic-emmanuel.picca at synchrotron-soleil.fr Fri Apr 19 16:29:23 2024 From: frederic-emmanuel.picca at synchrotron-soleil.fr (PICCA Frederic-Emmanuel) Date: Fri, 19 Apr 2024 18:29:23 +0200 (CEST) Subject: [Haskell-cafe] Is it possible to nest this kind of "continuation" (a -> b -> r) Message-ID: <834539043.7327380.1713544163589.JavaMail.zimbra@synchrotron-soleil.fr> Hello, I have this nest ∷ [(a → r) → r] → ([a] → r) → r nest xs = runCont (Prelude.mapM cont xs) but now I need this nest2 ∷ [(a → b → r) → r] → ([a] → [b] → r) → r nest2 xs = ... and this nest3 :: ... Do you think that there is a generic way to write all these nestX methodes. thanks for your help Frédéric From tom-lists-haskell-cafe-2023 at jaguarpaw.co.uk Fri Apr 19 16:59:59 2024 From: tom-lists-haskell-cafe-2023 at jaguarpaw.co.uk (Tom Ellis) Date: Fri, 19 Apr 2024 17:59:59 +0100 Subject: [Haskell-cafe] Is it possible to nest this kind of "continuation" (a -> b -> r) In-Reply-To: <834539043.7327380.1713544163589.JavaMail.zimbra@synchrotron-soleil.fr> References: <834539043.7327380.1713544163589.JavaMail.zimbra@synchrotron-soleil.fr> Message-ID: On Fri, Apr 19, 2024 at 06:29:23PM +0200, PICCA Frederic-Emmanuel wrote: > nest ∷ [(a → r) → r] → ([a] → r) → r > nest xs = runCont (Prelude.mapM cont xs) > > nest2 ∷ [(a → b → r) → r] → ([a] → [b] → r) → r > nest2 xs = ... > > nest3 :: ... > > Do you think that there is a generic way to write all these nestX methodes. I doubt it. There's not even a generic way of writing out the non-CPSed versions nest2 :: [(a, b)] -> ([a], [b]) nest3 :: [(a, b, c)] -> ([a], [b], [c]) Instead we just have individually-named unzip functions: https://www.stackage.org/haddock/lts-22.17/base-4.18.2.0/Prelude.html#v:unzip https://www.stackage.org/haddock/lts-22.17/base-4.18.2.0/Prelude.html#v:unzip3 Tom From godzbanebane at gmail.com Fri Apr 19 19:59:13 2024 From: godzbanebane at gmail.com (Georgi Lyubenov) Date: Fri, 19 Apr 2024 22:59:13 +0300 Subject: [Haskell-cafe] Is it possible to nest this kind of "continuation" (a -> b -> r) In-Reply-To: References: <834539043.7327380.1713544163589.JavaMail.zimbra@synchrotron-soleil.fr> Message-ID: <8dae800e-cb93-41db-8627-b1e8d4d86097@gmail.com> Well, if we used type indexed lists (aka just "dynamic tuples") it should be possible, right? I.e. hunzip :: [HList xs] -> HList (ToList xs) type family ToList xs where   ToList '[x] = [x]   ToList (x ': xs) = [x] ': ToList xs On 4/19/24 19:59, Tom Ellis wrote: > On Fri, Apr 19, 2024 at 06:29:23PM +0200, PICCA Frederic-Emmanuel wrote: >> nest ∷ [(a → r) → r] → ([a] → r) → r >> nest xs = runCont (Prelude.mapM cont xs) >> >> nest2 ∷ [(a → b → r) → r] → ([a] → [b] → r) → r >> nest2 xs = ... >> >> nest3 :: ... >> >> Do you think that there is a generic way to write all these nestX methodes. > I doubt it. There's not even a generic way of writing out the > non-CPSed versions > > nest2 :: [(a, b)] -> ([a], [b]) > nest3 :: [(a, b, c)] -> ([a], [b], [c]) > > Instead we just have individually-named unzip functions: > > https://www.stackage.org/haddock/lts-22.17/base-4.18.2.0/Prelude.html#v:unzip > https://www.stackage.org/haddock/lts-22.17/base-4.18.2.0/Prelude.html#v:unzip3 > > 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 anthony.d.clayden at gmail.com Sat Apr 20 05:05:42 2024 From: anthony.d.clayden at gmail.com (Anthony Clayden) Date: Sat, 20 Apr 2024 17:05:42 +1200 Subject: [Haskell-cafe] ghc should be able to deduce correct use of partial functions and not give a warning in such cases Message-ID: > > So your code is essentially pattern matching on a list to decide ..., then pattern matching on the Bool to split between two cases, then pattern matching on the list again. If you had kept the result of the first pattern match there would be no need for the latter two. > > Essentially the problem is "boolean blindness" ... > > This style of coding is generally more readable, maintainable, and less error-prone. ... > +1 to Ben's wise advice. +1 to "more readable". Haskell is a 'functional language' does not mean everything everywhere has to be expressed only through functions. Perhaps we should promote 'Algebraic data types' (yay mathy!) and 'pattern matching' right up front on the 'Features' section of Haskell.org? AntC -------------- next part -------------- An HTML attachment was scrubbed... URL: From george.colpitts at gmail.com Sat Apr 20 12:28:16 2024 From: george.colpitts at gmail.com (George Colpitts) Date: Sat, 20 Apr 2024 09:28:16 -0300 Subject: [Haskell-cafe] ghc should be able to deduce correct use of partial functions and not give a warning in such cases In-Reply-To: References: Message-ID: Thanks for everybody's replies To give more context the original code from Ch. 12 of Bird's *Thinking Functionally with Haskell* was: let (xs, ys) = break (== ch) str in if null ys then [] else [(xs, tail ys)]) I replaced it with let (xs, ys@(_ : t)) = break (== ch) str in if null ys then [] else [(xs, t)]) On Tue, Apr 16, 2024 at 10:51 AM George Colpitts wrote: > ghc should be able to deduce correct use of partial functions and not give > a warning in such cases, e.g. in 9.8.2 > > if null ys then [] else [(xs,tail ys)]) > > gets a warning > > warning: [GHC-63394] [-Wx-partial] > > but it is clear that this use of tail will never be a problem so IMHO that > line of code should not get a warning. > > Does anybody know if there is a plan or enhancement request to eliminate > such warnings? > > Cheers > George > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lemming at henning-thielemann.de Sat Apr 20 12:35:40 2024 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Sat, 20 Apr 2024 14:35:40 +0200 (CEST) Subject: [Haskell-cafe] ghc should be able to deduce correct use of partial functions and not give a warning in such cases In-Reply-To: References: Message-ID: <3de2d2a8-96d1-b6a8-3f4-62ef8bfd5bcb@henning-thielemann.de> On Sat, 20 Apr 2024, George Colpitts wrote: > Thanks for everybody's replies > > To give more context the original code from Ch. 12 of Bird's Thinking Functionally with Haskell was: > > let (xs, ys) = break (== ch) str in > >          if null ys then [] else [(xs, tail ys)]) > > I replaced it with  > > let (xs, ys@(_ : t)) = break (== ch) str in > >          if null ys then [] else [(xs, t)]) This won't work. ys@(_ : t) only matches on non-empty lists. It will also give you warnings, but this warning may not be contained in -Wall depending on the GHC version. From andrew.lelechenko at gmail.com Sat Apr 20 15:30:05 2024 From: andrew.lelechenko at gmail.com (Andrew Lelechenko) Date: Sat, 20 Apr 2024 16:30:05 +0100 Subject: [Haskell-cafe] ghc should be able to deduce correct use of partial functions and not give a warning in such cases In-Reply-To: References: Message-ID: Hi George, If you do not want to pattern match on `ys`, the simplest solution is to do what the GHC warning suggests you to do and use `drop 1` instead of `tail`. Another alternative is `Data.List.uncons` followed by `Data.Maybe.maybe`. Best regards, Andrew > On 20 Apr 2024, at 13:28, George Colpitts wrote: > > Thanks for everybody's replies > > To give more context the original code from Ch. 12 of Bird's Thinking Functionally with Haskell was: > > let (xs, ys) = break (== ch) str in > if null ys then [] else [(xs, tail ys)]) > > I replaced it with > > let (xs, ys@(_ : t)) = break (== ch) str in > if null ys then [] else [(xs, t)]) > > On Tue, Apr 16, 2024 at 10:51 AM George Colpitts > wrote: >> ghc should be able to deduce correct use of partial functions and not give a warning in such cases, e.g. in 9.8.2 >> >> if null ys then [] else [(xs,tail ys)]) >> >> gets a warning >> >> warning: [GHC-63394] [-Wx-partial] >> >> but it is clear that this use of tail will never be a problem so IMHO that line of code should not get a warning. >> >> Does anybody know if there is a plan or enhancement request to eliminate such warnings? >> >> Cheers >> George >> >> >> >> > _______________________________________________ > 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 george.colpitts at gmail.com Sat Apr 20 16:24:11 2024 From: george.colpitts at gmail.com (George Colpitts) Date: Sat, 20 Apr 2024 13:24:11 -0300 Subject: [Haskell-cafe] ghc should be able to deduce correct use of partial functions and not give a warning in such cases In-Reply-To: References: Message-ID: I've decided to stick with case and pattern matching as Henning suggested in his original reply. Thanks On Sat, Apr 20, 2024 at 12:30 PM Andrew Lelechenko < andrew.lelechenko at gmail.com> wrote: > Hi George, > > If you do not want to pattern match on `ys`, the simplest solution is to > do what the GHC warning suggests you to do and use `drop 1` instead of > `tail`. Another alternative is `Data.List.uncons` followed by > `Data.Maybe.maybe`. > > Best regards, > Andrew > > On 20 Apr 2024, at 13:28, George Colpitts > wrote: > > Thanks for everybody's replies > > To give more context the original code from Ch. 12 of Bird's *Thinking > Functionally with Haskell* was: > > > let (xs, ys) = break (== ch) str in > > if null ys then [] else [(xs, tail ys)]) > > I replaced it with > > let (xs, ys@(_ : t)) = break (== ch) str in > > if null ys then [] else [(xs, t)]) > > On Tue, Apr 16, 2024 at 10:51 AM George Colpitts < > george.colpitts at gmail.com> wrote: > >> ghc should be able to deduce correct use of partial functions and not >> give a warning in such cases, e.g. in 9.8.2 >> >> if null ys then [] else [(xs,tail ys)]) >> >> gets a warning >> >> warning: [GHC-63394] [-Wx-partial] >> >> but it is clear that this use of tail will never be a problem so IMHO >> that line of code should not get a warning. >> >> Does anybody know if there is a plan or enhancement request to eliminate >> such warnings? >> >> Cheers >> George >> >> >> >> >> _______________________________________________ > 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 raoknz at gmail.com Sun Apr 21 01:17:26 2024 From: raoknz at gmail.com (Richard O'Keefe) Date: Sun, 21 Apr 2024 13:17:26 +1200 Subject: [Haskell-cafe] ghc should be able to deduce correct use of partial functions and not give a warning in such cases In-Reply-To: References: Message-ID: The clearest way that I know to write that code fragment is case break (== ch) str of (_,[]) -> [] (xs,(_:ys)) -> [(xs,ys)] It's one line longer, but there are no warnings and NO SURPRISES for the reader. The version that matches on (_:_) before testing whether that's possible surprised me mightly. Confused me, even. On Sun, 21 Apr 2024 at 00:29, George Colpitts wrote: > > Thanks for everybody's replies > > To give more context the original code from Ch. 12 of Bird's Thinking Functionally with Haskell was: > > > let (xs, ys) = break (== ch) str in > > if null ys then [] else [(xs, tail ys)]) > > I replaced it with > > let (xs, ys@(_ : t)) = break (== ch) str in > > if null ys then [] else [(xs, t)]) > > On Tue, Apr 16, 2024 at 10:51 AM George Colpitts wrote: >> >> ghc should be able to deduce correct use of partial functions and not give a warning in such cases, e.g. in 9.8.2 >> >> if null ys then [] else [(xs,tail ys)]) >> >> gets a warning >> >> warning: [GHC-63394] [-Wx-partial] >> >> but it is clear that this use of tail will never be a problem so IMHO that line of code should not get a warning. >> >> Does anybody know if there is a plan or enhancement request to eliminate such warnings? >> >> Cheers >> George >> >> >> >> > _______________________________________________ > 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 kbh at umn.edu Sun Apr 21 14:33:50 2024 From: kbh at umn.edu (Favonia) Date: Sun, 21 Apr 2024 09:33:50 -0500 Subject: [Haskell-cafe] Student Research Competition (SRC) at ICFP 2024 Message-ID: ICFP 2024 Student Research Competition Call for Submissions ICFP 2024 invites students to participate in the Student Research Competition in order to present their research and get feedback from prominent members of the programming language research community. The SRC consists of three rounds: * Submission of an extended abstract * Poster session at ICFP 2024 * Finalists' presentations at ICFP 2024 During the first round students submit an extended abstract detailing their research to be reviewed by the program committee. Those students whose abstracts get accepted advance to the poster session round which will take place during ICFP 2024. Winners of the poster session advance to the next round, where they will give a 5-minute presentation about their work on the ICFP main stage in front of a live audience. ### IMPORTANT DATES AND TIMES * Submission Deadline: 23 May 2024 (Thursday) * Author Notification: 14 June 2024 (Friday) 12:00 PM CST * ICFP 2024 Conference in Milan, Italy: 2 September 2024 (Monday) - 7 September 2024 (Saturday) ### SUBMISSION OF EXTENDED ABSTRACTS * Submission Website: https://icfp24src.hotcrp.com Each submission (referred to as "abstract" below) should include the student author's name and e-mail address; institutional affiliation; research advisor's name; ACM student member number; category (undergraduate or graduate); research title; and an extended abstract addressing the following: * Problem and Motivation: Clearly state the problem being addressed and explain the reasons for seeking a solution to this problem. * Background and Related Work: Describe the specialized (but pertinent) background necessary to appreciate the work in the context of ICFP areas of interest. Include references to the literature where appropriate, and briefly explain where your work departs from that done by others. * Approach and Uniqueness: Describe your approach in addressing the problem and clearly state how your approach is novel. * Results and Contributions: Clearly show how the results of your work contribute to programming language design and implementation in particular and to computer science in general; explain the significance of those results. * Submissions must be original research that is not already published at ICFP or another conference or journal. One of the goals of the SRC is to give students feedback on ongoing, unpublished work. Furthermore, the abstract must be authored solely by the student. If the work is collaborative with others and/or part of a larger group project, the abstract should make clear what the student's role was and should focus on that portion of the work. * Formatting: Submissions must be in PDF format, printable in black and white on US Letter sized paper, and interpretable by common PDF tools. All submissions must adhere to the "ACM Small" template that is available (in both LaTeX and Word formats) from https://www.acm.org/publications/authors/submissions. For authors using LaTeX, a lighter-weight package, including only the essential files, is available from http://sigplan.org/Resources/Author/#acmart-format. The submission must not exceed 3 pages in PDF format. Reference lists do not count towards the 3-page limit. Further information is available at the ICFP SRC website: https://icfp24.sigplan.org/track/icfp-2024-student-research-competition -------------- next part -------------- An HTML attachment was scrubbed... URL: From ietf-dane at dukhovni.org Sun Apr 21 16:14:18 2024 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Sun, 21 Apr 2024 12:14:18 -0400 Subject: [Haskell-cafe] ghc should be able to deduce correct use of partial functions and not give a warning in such cases In-Reply-To: References: Message-ID: On Sun, Apr 21, 2024 at 01:17:26PM +1200, Richard O'Keefe wrote: > The clearest way that I know to write that code fragment is > case break (== ch) str of > (_,[]) -> [] > (xs,(_:ys)) -> [(xs,ys)] I'd also consider changing the return type from `[([a], [a])]` to `Maybe ([a], [a])`, as in: maybeSplit :: Eq a => a -> [a] -> Maybe ([a], [a]) maybeSplit sep xs = case break (== sep) xs of (ys, (_:zs)) -> Just (ys, zs) _ -> Nothing A list of at most one element begs to be a `Maybe` instead. -- Viktor. From trebla at vex.net Sun Apr 21 17:28:43 2024 From: trebla at vex.net (Albert Y. C. Lai) Date: Sun, 21 Apr 2024 13:28:43 -0400 Subject: [Haskell-cafe] Is it possible to nest this kind of "continuation" (a -> b -> r) In-Reply-To: <834539043.7327380.1713544163589.JavaMail.zimbra@synchrotron-soleil.fr> References: <834539043.7327380.1713544163589.JavaMail.zimbra@synchrotron-soleil.fr> Message-ID: <0f633b9f-de00-4a7b-a516-0ee73f36dfda@vex.net> I would think in terms of: nest :: Applicative f => [f a] -> f [a] nest = sequenceA nest2 :: Applicative f => [f (a,b)] -> f ([a],[b]) nest2 = fmap unzip . sequenceA nest3 :: Applicative f => [f (a,b,c)] -> f ([a],[b],[c]) nest3 = fmap unzip3 . sequenceA Then put f = Cont r On 2024-04-19 12:29, PICCA Frederic-Emmanuel wrote: > Hello, I have this > > nest ∷ [(a → r) → r] → ([a] → r) → r > nest xs = runCont (Prelude.mapM cont xs) > > but now I need this > > nest2 ∷ [(a → b → r) → r] → ([a] → [b] → r) → r > nest2 xs = ... > > and this > > nest3 :: ... > > Do you think that there is a generic way to write all these nestX methodes. > > thanks for your help > > Frédéric > _______________________________________________ > 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 sperber at deinprogramm.de Wed Apr 24 15:24:36 2024 From: sperber at deinprogramm.de (Michael Sperber) Date: Wed, 24 Apr 2024 17:24:36 +0200 Subject: [Haskell-cafe] 2nd Call for Papers: ACM Workshop on Functional Software Architecture [Deadline June 3] Message-ID: ====================================================================== *** FUNARCH 2024 -- CALL FOR PAPERS *** Second ACM SIGPLAN Workshop on Functional Software Architecture - FP in the Large 6th September 2024, Milan, Italy Co-located with ICFP 2024 https://functional-architecture.org/events/funarch-2024/ ====================================================================== TIMELINE: Paper submission 3rd June 2024 Author notification 30th June 2024 Camera ready copy 18th July 2024 Workshop 6th Sept 2024 BACKGROUND: "Functional Software Architecture" refers to methods of construction and structure of large and long-lived software projects that are implemented in functional languages and released to real users, typically in industry. The goals for the workshop are: - To assemble a community interested in software architecture techniques and technologies specific to functional programming; - To identify, categorize, and document topics relevant to the field of functional software architecture; - To connect the functional programming community to the software architecture community to cross-pollinate between the two. The workshop follows on from the Functional Software Architecture open space that was held at ICFP 2022 in Slovenia. SCOPE: The workshop seeks submissions in a range of categories: - You're a member of the FP community and have thought about how to support programming in the large, for example by framing functional ideas in architectural terms or vice verse, comparing different languages in terms of their architectural capabilities, clarifying architectural roles played by formal methods, proof assistants and DSLs, or observing how functional concepts are used in other language and architecture communities. Great, submit a research paper! - You're a member of the architecture community, and have thought about how your discipline might help functional programmers, for example by applying domain-driven design, implementing hexagonal architecture, or designing self-contained systems. Excellent, submit a research paper! - You've worked on a large project using functional programming, and it's worked out well, or terribly, or a mix of both; bonus points for deriving architectural principles from your experience. Wonderful, submit an experience report! - You know a neat architectural idiom or pattern that may be useful to others developing large functional software systems. Fabulous, submit an architectural pearl! - You have something that doesn't fit the above categories, but that still relates to functional software architecture, such as something that can be written up, or that could be part of the workshop format like a panel debate or a fishbowl. Superb, submit to the open category! Research papers should explain their research contributions in both general and technical terms, identifying what has been accomplished, explaining why it is significant, and relating it to previous work, and to other languages where appropriate. Experience reports and architectural pearls need not necessarily report original research results. The key criterion for such papers is that they make a contribution from which others can benefit. It is not enough simply to describe a large software system, or to present ideas that are specific to a particular system. Open category submissions that are not intended for publication are not required to follow the formatting guidelines, and can submit in PDF, word or plain text format as preferred. Not knowing what kinds of submissions we will receive, we cannot be specific as to how they will be evaluated. However, submissions that seem likely to stimulate discussion around practices in functional architecture are encouraged. If you are unsure whether your contribution is suitable, or if you need any kind of help with your submission, please email the program chairs at . Papers must be submitted by 3rd June 2024 using the EasyChair submission page: https://easychair.org/my/conference?conf=funarch2024 Formatting: submissions intended for publication must be in PDF format and follow the ACM SIGPLAN style guidelines, using the acmart format and the sigplan sub-format. Please use the review option when submitting, as this enables line numbers for easy reference in reviews. For further details, see SIGPLAN's author information: http://www.sigplan.org/Resources/Author/#acmart-format If your submission is not a research paper, please mark this using a subtitle (Experience Report, Architectural Pearl, Open Category). Length: submissions must adhere to the limits specified below. However, there is no requirement or expectation that all pages are used, and authors are encouraged to strive for brevity. Research papers 5 to 12+ pages Architectural pearls 5 to 12 pages Experience reports 3 to 6 pages Open category 1 to 6 pages Publication: The proceedings of FUNARCH 2024 will be published in the ACM Digital Library, and authors of accepted papers are required to agree to one of the standard ACM licensing options. Accepted papers must be presented at the workshop by one of the authors, but in special cases we may consider remote presentation. The official publication date is the date the papers are made available in the ACM Digital Library. This date may be up to two weeks prior to the first day of the conference. The official publication date affects the deadline for any patent filings related to published work. PROGRAM CHAIRS: Mike Sperber (Active Group, Germany) Perdita Stevens (University of Edinburgh, UK) PROGRAM COMMITTEE: Annette Bieniusa (University of Kaiserslautern) Jeffrey Young (IOG) Will Crichton (Brown University) Isabella Stilkerich (Schaeffler Technologies AG) Kiko Fernandez-Reyes (Ericsson) Ryan Scott (Galois) Satnam Singh (Groq) Facundo Dominguez (Tweag) Ilya Sergey (University of Singapore) Martin Elsman (University of Copenhagen) Benjamin Pierce (University of Pennsylvania) Matthew Flatt (University of Utah) Nada Amin (Harvard University) Richard Eisenberg (Jane Street) WORKSHOP VENUE: The workshop will be co-located with the ICFP 2024 conference at the Fiera Milano Congressi, Milan, Italy. From anthony.d.clayden at gmail.com Sat Apr 27 06:24:32 2024 From: anthony.d.clayden at gmail.com (Anthony Clayden) Date: Sat, 27 Apr 2024 18:24:32 +1200 Subject: [Haskell-cafe] Spurious [-Woverlapping-patterns] -- [cont] ghc should be able to deduce correct use of partial functions Message-ID: I think this is a similar 'failure to deduce' partiality as last week's thread; but the other way round (and with ViewPatterns) -- at GHC 8.10.7: GHCi> :set -XViewPatterns GHCi> :set -Wincomplete-patterns -- also warns overlapping GHCi> (\x -> case x of {((\(Just j) -> j) -> j2) -> j2; Nothing -> 'N'}) Nothing ===> : warning: [-Woverlapping-patterns] Pattern match is redundant In a case alternative: Nothing -> ... *** Exception: :16:21-34: Non-exhaustive patterns in lambda (Same Warning then same Exception if I compile the code.) So GHC isn't smart enough, despite the explicit `(\(Just j) -> ...)`, to see that ViewPattern usage is incomplete? I thought ViewPatterns got desugarred into clunky chains of nested `case`s, so that the pattern coverage checker could see what's going on? I was testing this because if anything I expected it to report coverage was incomplete. To get both a claim "Pattern match is redundant" and "Non-exhaustive" seems particularly unhelpful. AntC -------------- next part -------------- An HTML attachment was scrubbed... URL: From olf at aatal-apotheke.de Sat Apr 27 19:03:13 2024 From: olf at aatal-apotheke.de (Olaf Klinke) Date: Sat, 27 Apr 2024 21:03:13 +0200 Subject: [Haskell-cafe] Spurious [-Woverlapping-patterns] -- [cont] ghc should be able to deduce correct use of partial functions Message-ID: <10ba3f2a3bf10d01c64d846941572e09657e6d97.camel@aatal-apotheke.de> > I think this is a similar 'failure to deduce' partiality as last > week's > thread; but the other way round (and with ViewPatterns) -- at GHC > 8.10.7: > > GHCi> :set -XViewPatterns > GHCi> :set -Wincomplete-patterns -- also warns overlapping > GHCi> (\x -> case x of {((\(Just j) -> j) -> j2) -> j2; Nothing -> > 'N'}) > Nothing > > ===> : warning: [-Woverlapping-patterns] >  Pattern match is redundant >  In a case alternative: Nothing -> ... > *** Exception: :16:21-34: Non-exhaustive patterns in > lambda > > (Same Warning then same Exception if I compile the code.) I think what we see here is an instance of the fact that all checks must break down in presence of view patterns. If I parsed your code correctly, the case analysis has two branches. The first uses a view pattern with a function, call it v for the moment. The result of v is bound to another pattern, in your case the wildcard j2 and that is returned as-is, so in pseudo-Haskell: case (v x) of j2 -> j2 case x of Nothing -> 'N' Now your view function v happens to be partial, it pattern-matches its argument and only provides a branch for the Just case.  v = \(Just j) -> j = Data.Maybe.fromJust That is why you see the exception when you call this function with 'Nothing'. And indeed the second match is redundant insofar as the view pattern will evaluate v for any x. Since v could be anything, like unsafePerformIO (lauchMissiles >> return j) GHC does not examine this and thus can not decide that v does not match the cases that the Nothing branch does. If you swap the two branches and make the view pattern the last one, then both the exception and the warning go away. Olaf From anthony.d.clayden at gmail.com Sun Apr 28 10:29:30 2024 From: anthony.d.clayden at gmail.com (Anthony Clayden) Date: Sun, 28 Apr 2024 22:29:30 +1200 Subject: [Haskell-cafe] Spurious [-Woverlapping-patterns] -- [cont] ghc should be able to deduce correct use of partial functions In-Reply-To: <10ba3f2a3bf10d01c64d846941572e09657e6d97.camel@aatal-apotheke.de> References: <10ba3f2a3bf10d01c64d846941572e09657e6d97.camel@aatal-apotheke.de> Message-ID: > On Sun, 28 Apr 2024 at 07:03, Olaf Klinke wrote: > I think what we see here is an instance of the fact that all checks > must break down in presence of view patterns. Sadly, yes. I'd originally tried that example with a view pattern `fromJust`, to keep closer to last week's o.p. Switching to explicit constructor didn't help. To contrast with other pattern-related styles: * with guards, GHC can see the coverage, doesn't complain, works fine. * with Pattern Synonyms (at least simple bidir ones) GHC complains about non-exhaustiveness, but in fact works fine. * with PattSyns defined explicitly bidir using a View Pattern, again checks break down. As well as the 'Boolean blindness' mentioned on that thread, there's 'Maybe blindness' or even 'algebraic blindness' https://github.com/quchen/articles/blob/master/algebraic-blindness.md (and more articles/threads via Google). Walk a data structure (could be a JSON), come back with a bunch of Maybes, now too easy to confuse which means what. The 'audit trail' has gone cold. -------------- next part -------------- An HTML attachment was scrubbed... URL: From olf at aatal-apotheke.de Mon Apr 29 05:58:56 2024 From: olf at aatal-apotheke.de (Olaf Klinke) Date: Mon, 29 Apr 2024 07:58:56 +0200 Subject: [Haskell-cafe] Spurious [-Woverlapping-patterns] -- [cont] ghc should be able to deduce correct use of partial functions In-Reply-To: References: <10ba3f2a3bf10d01c64d846941572e09657e6d97.camel@aatal-apotheke.de> Message-ID: <875c236012cf83b0b128e3629a7fd2678606da36.camel@aatal-apotheke.de> On Sun, 2024-04-28 at 22:29 +1200, Anthony Clayden wrote: > > On Sun, 28 Apr 2024 at 07:03, Olaf Klinke > > wrote: > > >  I think what we see here is an instance of the fact that all > > checks > > must break down in presence of view patterns. > > Sadly, yes. I'd originally tried that example with a view pattern > `fromJust`, to keep closer to last week's o.p. Switching to explicit > constructor didn't help. > To contrast with other pattern-related styles: > > * with guards, GHC can see the coverage, doesn't complain, works > fine. > > * with Pattern Synonyms (at least simple bidir ones) GHC complains > about > non-exhaustiveness, but in fact works fine. > > * with PattSyns defined explicitly bidir using a View Pattern, again > checks > break down. > > > As well as the 'Boolean blindness' mentioned on that thread, there's > 'Maybe > blindness' > or even 'algebraic blindness' > https://github.com/quchen/articles/blob/master/algebraic-blindness.md > (and more articles/threads via Google). > Walk a data structure (could be a JSON), come back with a bunch of > Maybes, > now too easy to confuse which means what. > The 'audit trail' has gone cold. I believe that completeness can be decidable, if we only could restrict the functions that are allowed in view patterns to so-called perfect maps. See https://mail.haskell.org/pipermail/haskell-cafe/2024-January/136556.html The key insights are: 1. Every data type (except Integer) has only a finite number of constructors and thereby a finite number of primary patterns to match on. 2. Every pattern corresponds to a Boolean predicate on the type. Ordinary pattern matching makes this predicate decidable. 3. In every Boolean algebra, it is decidable whether the disjunction of formulas (the cases of the pattern match) is true (the match is complete). If we could restrict the functions allowed in view patterns to those functions that preserve preimages of decidable subsets [*], then the entirety of Haskell patterns could be decidable. Olaf [*] More precisely: Let f :: a -> b and let P be a pattern on b that is decidable, that is, the corresponding predicate isP :: b -> Bool is decidable. There is the predicate isP.f :: a -> Bool but it need not be deciable. If it is for every P, the function f is called perfect. From kkmicins at syr.edu Tue Apr 30 00:52:01 2024 From: kkmicins at syr.edu (Kristopher K Micinski) Date: Tue, 30 Apr 2024 00:52:01 +0000 Subject: [Haskell-cafe] Call for Papers: Scheme '24 Message-ID: -------------------------------------------------------------------------------- CALL FOR PAPERS The 2024 Workshop on Scheme and Functional Programming Co-located with ICFP 2024 (Milan, Italy) https://icfp24.sigplan.org/home/scheme-2024 -------------------------------------------------------------------------------- The 2024 Scheme and Functional Programming Workshop is calling for submissions. We invite high-quality papers and talk proposals about novel research results, lessons learned from practical experience in an industrial or educational setting, and even new insights on old ideas. We welcome and encourage submissions that apply to any dynamic functional language, especially those that can be considered a Scheme: from strict subsets of RnRS to other "Scheme" implementations, to Racket, to Lisp dialects including Clojure, Emacs Lisp, Common Lisp, to functional languages with continuations and/or macros (or extended to have them) such as Dylan, ECMAScript, Hop, Lua, Scala, Rust, etc. The elegance of the paper and the relevance of its topic to the interests of Schemers will matter more than the surface syntax of the examples used. * Topics Topics of interest include (but are not limited to): - Interaction: program-development environments, debugging, testing, refactoring - Implementation: interpreters, compilers, tools, garbage collectors, benchmarks - Extension: macros, hygiene, domain-specific languages, reflection, and how such extension affects interaction - Expression: control, modularity, ad hoc and parametric polymorphism, types, aspects, ownership models, concurrency, distribution, parallelism, non-determinism, probabilism, and other programming paradigms - Integration: build tools, deployment, interoperation with other languages and systems - Formal semantics: theory, analyses and transformations, partial evaluation - Human factors: past, present and future history, evolution and sociology of the language Scheme, its standard and its dialects - Education: approaches, experiences, curricula - Applications: industrial uses of Scheme - Scheme pearls: elegant, instructive uses of Scheme * Dates - Submission deadline is Thursday July 18, 2024. - Authors will be notified by Monday August 12, 2024. - Camera-ready versions are due Thursday August 29, 2024. - Workshop will be held in Milan, Italy on Saturday September 7, 2024. All deadlines are 23:59 UTC-12, anywhere on Earth. * Submission Information We encourage all kinds of submissions, including full papers, experience reports, and lightning talks. Papers and experience reports are expected to be 10–24 pages in length using the single-column SIGPLAN acmart style. (For reference, this is about 5–12 pages of the older SIGPLAN 2-column 9pt style.) Abstracts submitted for lightning talks should be limited to 192 words. Authors of each accepted submission are invited to attend and be available for the presentation of that paper at the conference. The schedule for presentations will be determined and shared with authors after the full program has been selected. The size limits above exclude references and any optional appendices. There are no size limits on appendices, but the papers should stand without the need to read them, and reviewers are not required to read them. Authors are encouraged to publish any code associated to their papers under an open source license, so that reviewers may try the code and verify the claims. Proceedings will be uploaded to arXiv.org (https://arXiv.org/). Publication of a paper at this workshop is not intended to replace conference or journal publication, and does not preclude re-publication of a more complete or finished version of the paper at some later conference or in a journal. Please submit papers through the workshop's HotCRP site (https://scheme2024.hotcrp.com/). * Lightweight double-blind reviewing Scheme 2024 will use lightweight double-blind reviewing. Submitted papers must omit author names and institutions and reference the authors’ own related work in the third person (e.g., not “we build on our previous work…” but rather “we build on the work of…”). The purpose is to help the reviewers come to an initial judgment about the paper without bias, not to make it impossible for them to discover the authors if they were to try. Nothing should be done in the name of anonymity that weakens the submission or makes the job of reviewing the paper more difficult (e.g., important background references should not be omitted or anonymized). * Formatting Information Full papers and experience reports should use the SIGPLAN acmsmall option to acmart. We recommend using the anonymous and review options to acmart when submitting a paper; these options hide the author names and enable line numbers for easy reference in review. LaTeX and Microsoft Word templates for this format are available through SIGPLAN (https://www.sigplan.org/Resources/Author/). Lightning talks can be submitted as either a text file or a PDF file. * Workshop Organization Organizing Committee: Kristopher Micinski (Syracuse University, United States) Youyou Cong (Tokyo Institute of Technology, Japan) Program Committee: Julia Belyakova (Purdue University, United States) Kimball Germane (Brigham Young University, United States) Yuki Nishida (Kyoto University, Japan) Gabriel Scherer (Inria Saclay, France) Philipp Schuster (University of Tübingen, Germany) Taro Sekiyama (National Institute of Informatice, Japan) Michael Sperber (Active Group GmbH, Germany)