From matthewtpickering at gmail.com Tue Aug 2 16:29:53 2022 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Tue, 2 Aug 2022 17:29:53 +0100 Subject: [Haskell-cafe] [ANNOUNCE] GHC 9.4.1-rc1 is now available In-Reply-To: <20220725.132317.759628945463268605.kazu@iij.ad.jp> References: <87bktgyo9s.fsf@smart-cactus.org> <20220725.132317.759628945463268605.kazu@iij.ad.jp> Message-ID: George, Kazu, I also can't reproduce on the mac which I can access over SSH. I downloaded the bindist for 9.2.4 and 9.4.1-rc1 and could install them both and run the binaries. Matt On Mon, Jul 25, 2022 at 5:23 AM Kazu Yamamoto (山本和彦) via ghc-devs wrote: > > Hi George, > > > I've duplicated the issue on both of my machines. It would be good to know > > if anybody else is seeing it. Kazu, I know you have seen this in the past. > > Do you get the same error installing rc1? > > When I run sudo make install I get a popup that says: > > I had no problem on 9.4.1-rc1. > "xattr -rc ." and "make install" worked perfectly. > > macOS Monterey v12.4 > Xcode 13.4.1 > > --Kazu > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From matthewtpickering at gmail.com Wed Aug 3 09:17:19 2022 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Wed, 3 Aug 2022 10:17:19 +0100 Subject: [Haskell-cafe] [ANNOUNCE] GHC 9.4.1-rc1 is now available In-Reply-To: References: <87o7xhz4ax.fsf@smart-cactus.org> Message-ID: Hi Henning, I can't reproduce this error you are seeing. How are you installing the compiler? GHC should use the in-tree libffi which is the correct version. https://gitlab.haskell.org/ghc/ghc/-/issues/21956#note_446298 On Thu, Jul 28, 2022 at 5:27 PM Henning Thielemann wrote: > > > On Fri, 22 Jul 2022, Ben Gamari wrote: > > > The GHC developers are happy to announce the availability of the first > > (and likely last) release candidate of GHC 9.4.1. Binary distributions, source > > distributions, and documentation are available at [downloads.haskell.org]. > > I try > > https://downloads.haskell.org/ghc/9.4.1-rc1/ghc-9.4.0.20220721-x86_64-deb11-linux.tar.lz > > on Debian 11. > > $ /usr/local/ghc-9.4.0/bin/ghc --version > /usr/local/ghc-9.4.0/lib/ghc-9.4.0.20220721/bin/ghc-9.4.0.20220721: error > while loading shared libraries: libffi.so.8: cannot open shared object > file: No such file or directory > > > Debian 11 seems to support only libffi7: > > $ dpkg --list "*libffi*" > > ii libffi-dev:amd64 3.3-6 amd64 Foreign Function Interface library (development files) > un libffi4-dev (keine Beschreibung vorhanden) > ii libffi7:amd64 3.3-6 amd64 Foreign Function Interface library runtime > ii libffi7:i386 3.3-6 i386 Foreign Function Interface library runtime > > > I think this dependency is new and was not present in the Alpha releases. > > > > Also many directories have no read and cd permissions for 'other' users. > _______________________________________________ > 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 lemming at henning-thielemann.de Wed Aug 3 09:41:55 2022 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Wed, 3 Aug 2022 11:41:55 +0200 (CEST) Subject: [Haskell-cafe] [ANNOUNCE] GHC 9.4.1-rc1 is now available In-Reply-To: References: <87o7xhz4ax.fsf@smart-cactus.org>

Message-ID: <398c3f26-72dd-dab1-d51c-2234cbaed38b@henning-thielemann.de> On Wed, 3 Aug 2022, Matthew Pickering wrote: > Hi Henning, I can't reproduce this error you are seeing. How are you > installing the compiler? I used this archive: https://downloads.haskell.org/ghc/9.4.1-rc1/ghc-9.4.0.20220721-x86_64-deb11-linux.tar.lz $ tar xf ghc-9.4.0.20220721-x86_64-deb11-linux.tar.lz $ cd ghc-9.4.0.20220721-x86_64-unknown-linux/ $ ./configure --prefix=/usr/local/ghc-9.4.0 $ sudo make install > GHC should use the in-tree libffi which is the correct version. Interesting, maybe it is not used because it has wrong permissions, like some other files. From matthewtpickering at gmail.com Wed Aug 3 14:57:39 2022 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Wed, 3 Aug 2022 15:57:39 +0100 Subject: [Haskell-cafe] [ANNOUNCE] GHC 9.4.1-rc1 is now available In-Reply-To: <398c3f26-72dd-dab1-d51c-2234cbaed38b@henning-thielemann.de> References: <87o7xhz4ax.fsf@smart-cactus.org>

<398c3f26-72dd-dab1-d51c-2234cbaed38b@henning-thielemann.de> Message-ID: Hi Henning, which files in particular have the wrong permissions? They look fine on my machine. Matt On Wed, Aug 3, 2022 at 10:42 AM Henning Thielemann wrote: > > > On Wed, 3 Aug 2022, Matthew Pickering wrote: > > > Hi Henning, I can't reproduce this error you are seeing. How are you > > installing the compiler? > > I used this archive: > https://downloads.haskell.org/ghc/9.4.1-rc1/ghc-9.4.0.20220721-x86_64-deb11-linux.tar.lz > > $ tar xf ghc-9.4.0.20220721-x86_64-deb11-linux.tar.lz > $ cd ghc-9.4.0.20220721-x86_64-unknown-linux/ > $ ./configure --prefix=/usr/local/ghc-9.4.0 > $ sudo make install > > > > GHC should use the in-tree libffi which is the correct version. > > Interesting, maybe it is not used because it has wrong permissions, like > some other files. From lemming at henning-thielemann.de Thu Aug 4 19:25:52 2022 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Thu, 4 Aug 2022 21:25:52 +0200 (CEST) Subject: [Haskell-cafe] [ANNOUNCE] GHC 9.4.1-rc1 is now available In-Reply-To: References: <87o7xhz4ax.fsf@smart-cactus.org>

<398c3f26-72dd-dab1-d51c-2234cbaed38b@henning-thielemann.de> Message-ID: <7943a73e-e668-73b2-76ad-2f6f76f6bc70@henning-thielemann.de> On Wed, 3 Aug 2022, Matthew Pickering wrote: > Hi Henning, which files in particular have the wrong permissions? They > look fine on my machine. $ ls -al /usr/local/ghc-9.4.0/lib/ghc-9.4.0.20220721/bin/ drwxr-xr-x 2 root root 520 4. Aug 16:19 . drwxr-xr-x 4 root root 80 4. Aug 16:19 .. lrwxrwxrwx 1 root root 18 4. Aug 16:19 ghc -> ghc-9.4.0.20220721 -rwx------ 1 root root 2150120 4. Aug 16:19 ghc-9.4.0.20220721 lrwxrwxrwx 1 root root 28 4. Aug 16:19 ghc-iserv -> ghc-iserv-ghc-9.4.0.20220721 lrwxrwxrwx 1 root root 32 4. Aug 16:19 ghc-iserv-dyn -> ghc-iserv-dyn-ghc-9.4.0.20220721 -rwx------ 1 root root 34856 4. Aug 16:19 ghc-iserv-dyn-ghc-9.4.0.20220721 -rwx------ 1 root root 32991032 4. Aug 16:19 ghc-iserv-ghc-9.4.0.20220721 lrwxrwxrwx 1 root root 33 4. Aug 16:19 ghc-iserv-prof -> ghc-iserv-prof-ghc-9.4.0.20220721 -rwx------ 1 root root 53225472 4. Aug 16:19 ghc-iserv-prof-ghc-9.4.0.20220721 lrwxrwxrwx 1 root root 22 4. Aug 16:19 ghc-pkg -> ghc-pkg-9.4.0.20220721 -rwx------ 1 root root 475864 4. Aug 16:19 ghc-pkg-9.4.0.20220721 lrwxrwxrwx 1 root root 26 4. Aug 16:19 haddock -> haddock-ghc-9.4.0.20220721 -rwx------ 1 root root 5448368 4. Aug 16:19 haddock-ghc-9.4.0.20220721 lrwxrwxrwx 1 root root 24 4. Aug 16:19 hp2ps -> hp2ps-ghc-9.4.0.20220721 -rwx------ 1 root root 43696 4. Aug 16:19 hp2ps-ghc-9.4.0.20220721 lrwxrwxrwx 1 root root 22 4. Aug 16:19 hpc -> hpc-ghc-9.4.0.20220721 -rwx------ 1 root root 647312 4. Aug 16:19 hpc-ghc-9.4.0.20220721 lrwxrwxrwx 1 root root 25 4. Aug 16:19 hsc2hs -> hsc2hs-ghc-9.4.0.20220721 -rwx------ 1 root root 694104 4. Aug 16:19 hsc2hs-ghc-9.4.0.20220721 lrwxrwxrwx 1 root root 21 4. Aug 16:19 runghc -> runghc-9.4.0.20220721 -rwx------ 1 root root 51704 4. Aug 16:19 runghc-9.4.0.20220721 lrwxrwxrwx 1 root root 21 4. Aug 16:19 runhaskell -> runghc-9.4.0.20220721 lrwxrwxrwx 1 root root 21 4. Aug 16:19 runhaskell-9.4.0.20220721 -> runghc-9.4.0.20220721 lrwxrwxrwx 1 root root 24 4. Aug 16:19 unlit -> unlit-ghc-9.4.0.20220721 -rwx------ 1 root root 13248 4. Aug 16:19 unlit-ghc-9.4.0.20220721 $ find /usr/local/ghc-9.4.0/ -iname "libffi*" find: ‘/usr/local/ghc-9.4.0/share/doc/ghc-9.4.0.20220721/html’: no permission find: ‘/usr/local/ghc-9.4.0/share/doc/ghc-9.4.0.20220721/archives’: no permission find: ‘/usr/local/ghc-9.4.0/lib/ghc-9.4.0.20220721/lib/x86_64-linux-ghc-9.4.0.20220721’: no permission find: ‘/usr/local/ghc-9.4.0/lib/ghc-9.4.0.20220721/lib/package.conf.d’: no permission find: ‘/usr/local/ghc-9.4.0/lib/ghc-9.4.0.20220721/lib/latex’: no permission find: ‘/usr/local/ghc-9.4.0/lib/ghc-9.4.0.20220721/lib/html’: no permission find: ‘/usr/local/ghc-9.4.0/lib/ghc-9.4.0.20220721/lib/bin’: no permission From ben at smart-cactus.org Thu Aug 4 21:06:55 2022 From: ben at smart-cactus.org (Ben Gamari) Date: Thu, 04 Aug 2022 17:06:55 -0400 Subject: [Haskell-cafe] [ANNOUNCE] GHC 9.4.1-rc1 is now available In-Reply-To: <7943a73e-e668-73b2-76ad-2f6f76f6bc70@henning-thielemann.de> References: <87o7xhz4ax.fsf@smart-cactus.org>

<398c3f26-72dd-dab1-d51c-2234cbaed38b@henning-thielemann.de> <7943a73e-e668-73b2-76ad-2f6f76f6bc70@henning-thielemann.de> Message-ID: <87iln7yazr.fsf@smart-cactus.org> Henning Thielemann writes: > On Wed, 3 Aug 2022, Matthew Pickering wrote: > >> Hi Henning, which files in particular have the wrong permissions? They >> look fine on my machine. > I suspect that the problem is that Hadrian's bindist Makefile is using plain `cp` to copy binaries, etc. into place. This is almost certainly wrong. We should be using either `install` or, at very least, `cp -p`. That being said, like Matt, I am also unable to reproduce this locally in a Debian 11 docker image. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From ben at smart-cactus.org Thu Aug 4 21:27:18 2022 From: ben at smart-cactus.org (Ben Gamari) Date: Thu, 04 Aug 2022 17:27:18 -0400 Subject: [Haskell-cafe] [ANNOUNCE] GHC 9.4.1-rc1 is now available In-Reply-To: <87iln7yazr.fsf@smart-cactus.org> References: <87o7xhz4ax.fsf@smart-cactus.org>

<398c3f26-72dd-dab1-d51c-2234cbaed38b@henning-thielemann.de> <7943a73e-e668-73b2-76ad-2f6f76f6bc70@henning-thielemann.de> <87iln7yazr.fsf@smart-cactus.org> Message-ID: <87czdfya1v.fsf@smart-cactus.org> Ben Gamari writes: > Henning Thielemann writes: > >> On Wed, 3 Aug 2022, Matthew Pickering wrote: >> >>> Hi Henning, which files in particular have the wrong permissions? They >>> look fine on my machine. >> > I suspect that the problem is that Hadrian's bindist Makefile is using > plain `cp` to copy binaries, etc. into place. This is almost certainly > wrong. We should be using either `install` or, at very least, `cp -p`. > I have opened #21965 to track this issue. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From lemming at henning-thielemann.de Thu Aug 4 22:01:45 2022 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Fri, 5 Aug 2022 00:01:45 +0200 (CEST) Subject: [Haskell-cafe] [ANNOUNCE] GHC 9.4.1-rc1 is now available In-Reply-To: <87iln7yazr.fsf@smart-cactus.org> References: <87o7xhz4ax.fsf@smart-cactus.org>

<398c3f26-72dd-dab1-d51c-2234cbaed38b@henning-thielemann.de> <7943a73e-e668-73b2-76ad-2f6f76f6bc70@henning-thielemann.de> <87iln7yazr.fsf@smart-cactus.org> Message-ID: <4bb6c923-1e99-7193-4d56-129ab621c6b@henning-thielemann.de> On Thu, 4 Aug 2022, Ben Gamari wrote: > Henning Thielemann writes: > >> On Wed, 3 Aug 2022, Matthew Pickering wrote: >> >>> Hi Henning, which files in particular have the wrong permissions? They >>> look fine on my machine. > > I suspect that the problem is that Hadrian's bindist Makefile is using > plain `cp` to copy binaries, etc. into place. This is almost certainly > wrong. We should be using either `install` or, at very least, `cp -p`. I guess that 'install' is better, yes. > That being said, like Matt, I am also unable to reproduce this locally > in a Debian 11 docker image. strange From ben at smart-cactus.org Fri Aug 5 01:23:55 2022 From: ben at smart-cactus.org (Ben Gamari) Date: Thu, 04 Aug 2022 21:23:55 -0400 Subject: [Haskell-cafe] [ANNOUNCE] GHC 9.4.1-rc1 is now available In-Reply-To: <4bb6c923-1e99-7193-4d56-129ab621c6b@henning-thielemann.de> References: <87o7xhz4ax.fsf@smart-cactus.org>

Message-ID: On my current machine, yes. On various machines in the past, no; but anything I wasn't comfortable with others seeing didn't touch those machines, because if nothing else (other) sysadmins would see them. So 022 was an acceptable umask. On Mon, Aug 8, 2022 at 10:02 AM Henning Thielemann wrote: > > > On Mon, 8 Aug 2022, Brandon Allbery wrote: > > > I think umask addresses a different issue than "unprivileged user". In > > any case, yes, 077 is fairly uncommon; if you have that much need for > > privacy then perhaps you should not be using the system in the first > > place. > > Are you the only user on the machine? -- brandon s allbery kf8nh allbery.b at gmail.com From spam at scientician.net Mon Aug 8 17:18:46 2022 From: spam at scientician.net (Bardur Arantsson) Date: Mon, 8 Aug 2022 19:18:46 +0200 Subject: [Haskell-cafe] GHC bindist permissions (Was: [ANNOUNCE] GHC 9.4.1-rc1 is now available) In-Reply-To: References: <87o7xhz4ax.fsf@smart-cactus.org>

<398c3f26-72dd-dab1-d51c-2234cbaed38b@henning-thielemann.de> <7943a73e-e668-73b2-76ad-2f6f76f6bc70@henning-thielemann.de> <87iln7yazr.fsf@smart-cactus.org> <4bb6c923-1e99-7193-4d56-129ab621c6b@henning-thielemann.de> <871qtvxz3k.fsf@smart-cactus.org> <87y1w2w9k9.fsf@smart-cactus.org> <4f5b772f-c897-2b2-274-83a8a632a1a@henning-thielemann.de> <87leryx2ta.fsf@smart-cactus.org> Message-ID: On 08/08/2022 15.59, Brandon Allbery wrote: > I think umask addresses a different issue than "unprivileged user". In > any case, yes, 077 is fairly uncommon; if you have that much need for > privacy then perhaps you should not be using the system in the first > place. > Yes and no. It prevents a program which drops privileges (e.g. sshd) at the start from reading arbitrary user files, so if there are post-startup remote vulnerabilities it's unable to exfiltrate all your user data. (Obviously one has to trust the program up to that point, but that's a much smaller attack surface.) I find it a good general practice in terms of Defense in Depth -- especially as it actually really shouldn't cause issues one a single-user system. (It *is* probably uncommon as you say, though. I believe most distros default to 022.) Regards, From olf at aatal-apotheke.de Tue Aug 9 19:34:07 2022 From: olf at aatal-apotheke.de (Olaf Klinke) Date: Tue, 09 Aug 2022 21:34:07 +0200 Subject: [Haskell-cafe] Haskell SQL backends: How is data handed over? Message-ID: Dear Café, I was discussing with a friend the fastest way to shovel data into a SQL database after parsing the raw (textual) data with Haskell. I am concerned about numeric conversion: In my experience parsing the file structure is fast. The majority of the time is spent converting strings of digits to numbers. I hoped that once Haskell has constructed a Double, the backend driver can hand that binary value over to the database engine. But Database.HDBC.Statement has a field orginalQuery :: String and HDBC has functions prepare :: Connection -> String -> IO Statement run :: Connection -> String -> [SqlValue] -> IO Integer which makes me wonder whether the backend constructs a complete SQL query statement in form of a string (including the SqlValues), and hands that to the database driver to parse. Is that indeed so? If yes, the numbers should never be parsed in the first place: The DB will do that anyways. I might as well construct a new CSV file and let the database do a bulk insert on that. The above is specific to the HDBC backend. If there are other backends/frameworks that do the marshalling more efficiently, please let me know. Thanks Olaf From anthony.d.clayden at gmail.com Tue Aug 9 20:50:55 2022 From: anthony.d.clayden at gmail.com (Anthony Clayden) Date: Wed, 10 Aug 2022 08:50:55 +1200 Subject: [Haskell-cafe] Haskell SQL backends: How is data handed over? Message-ID: > the backend constructs a complete SQL query statement in form of a string (including the SqlValues), and hands that to the database driver to parse. Is that indeed so? > Hi Olaf, that's the usual format for any HLL to pass statements (queries or updates) to SQL. Most HLLs provide some sort of modulate/demodulate so your program doesn't see the raw numbers-as-strings, but the parsing is going on in the background. Going via CSV isn't really saving anything: the "bulk insert" is again parsing those commas and the bits in between. (A dedicated SQL engine is probably more efficient than Haskell's string handling.) AntC -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Tue Aug 9 20:53:58 2022 From: allbery.b at gmail.com (Brandon Allbery) Date: Tue, 9 Aug 2022 16:53:58 -0400 Subject: [Haskell-cafe] Haskell SQL backends: How is data handed over? In-Reply-To: References: Message-ID: More specifically, a query or DML statement is a string with ? placeholders for values, which is "prepare"d to turn it into internal format and then executed one or more times with values supplied. On Tue, Aug 9, 2022 at 4:51 PM Anthony Clayden wrote: > > > the backend constructs a complete SQL query statement in form of a string (including the SqlValues), and hands that to the database driver to parse. Is that indeed so? > > > > Hi Olaf, that's the usual format for any HLL to pass statements (queries or updates) to SQL. > > Most HLLs provide some sort of modulate/demodulate so your program doesn't see the raw numbers-as-strings, but the parsing is going on in the background. > > Going via CSV isn't really saving anything: the "bulk insert" is again parsing those commas and the bits in between. (A dedicated SQL engine is probably more efficient than Haskell's string handling.) > > AntC > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -- brandon s allbery kf8nh allbery.b at gmail.com From shayne.fletcher.50 at gmail.com Tue Aug 9 22:40:48 2022 From: shayne.fletcher.50 at gmail.com (Shayne Fletcher) Date: Tue, 9 Aug 2022 18:40:48 -0400 Subject: [Haskell-cafe] ghc doesn't work after installing 9.4.1 on my Mac In-Reply-To: References: Message-ID: Known issue George. See e.g. https://gitlab.haskell.org/ghc/ghc/-/issues/21985 On Tue, Aug 9, 2022, 4:33 PM George Colpitts wrote: > Unfortunately ghc doesn't work after installing 9.4.1 on my Mac. Does it > work for others? > > After the install finishes when I do the following: > > $ ghc --version > bash: /usr/local/bin/ghc: Permission denied > $ sudo chmod +x /usr/local/bin/ghc > $ghc --version > /usr/local/bin/ghc: line 1: exec: : not found > $ cat /usr/local/bin/ghc > exec "$executablename" -B"$libdir" ${1+"$@"} > $ cat /usr/local/bin/ghc-9.4.1 > #!/bin/sh > exedir="/usr/local/lib/ghc-9.4.1/bin" > exeprog="ghc-9.4.1" > executablename="/usr/local/lib/ghc-9.4.1/bin/ghc-9.4.1" > bindir="/usr/local/bin" > libdir="/usr/local/lib/ghc-9.4.1/lib" > docdir="/usr/local/share/doc/ghc-9.4.1" > includedir="/usr/local/include" > > exec "$executablename" -B"$libdir" ${1+"$@"} > > > Thanks > George > > > > On Sun, Aug 7, 2022 at 6:30 PM Ben Gamari wrote: > >> The GHC developers are very pleased to announce the availability of GHC >> 9.4.1. Binary distributions, source distributions, and documentation are >> available at downloads.haskell.org: >> >> https://downloads.haskell.org/ghc/9.4.1 >> >> This release includes: >> >> - A new profiling mode, `-fprof-late`, which adds automatic cost-center >> annotations to all top-level functions *after* Core optimisation has >> run. This provides informative profiles while interfering >> significantly less with GHC's aggressive optimisations, making it >> easier to understand the performance of programs which depend upon >> simplification.. >> >> - A variety of plugin improvements including the introduction of a new >> plugin type, *defaulting plugins*, and the ability for typechecking >> plugins to rewrite type-families. >> >> - An improved constructed product result analysis, allowing unboxing of >> nested structures, and a new boxity analysis, leading to less reboxing. >> >> - Introduction of a tag-check elision optimisation, bringing >> significant performance improvements in strict programs. >> >> - Generalisation of a variety of primitive types to be levity >> polymorphic. Consequently, the `ArrayArray#` type can at long last be >> retired, replaced by standard `Array#`. >> >> - Introduction of the `\cases` syntax from [GHC proposal 0302]. >> >> - A complete overhaul of GHC's Windows support. This includes a >> migration to a fully Clang-based C toolchain, a deep refactoring of >> the linker, and many fixes in WinIO. >> >> - Support for multiple home packages, significantly improving support >> in IDEs and other tools for multi-package projects. >> >> - A refactoring of GHC's error message infrastructure, allowing GHC to >> provide diagnostic information to downstream consumers as structured >> data, greatly easing IDE support. >> >> - Significant compile-time improvements to runtime and memory >> consumption. >> >> - On overhaul of our packaging infrastructure, allowing full >> traceability of release artifacts and more reliable binary >> distributions. >> >> - Reintroduction of deep subsumption (which was previously dropped with >> the >> *simplified subsumption* change) as a language extension. >> >> - ... and much more. See the [release notes] for a full accounting. >> >> Note that, as 9.4.1 is the first release for which the released artifacts >> will >> all be generated by our Hadrian build system, it is possible that there >> will be >> packaging issues. If you enounter trouble while using a binary >> distribution, >> please open a [ticket]. Likewise, if you are a downstream packager, do >> consider >> migrating to [Hadrian] to run your build; the Hadrian build system can be >> built >> using `cabal-install`, `stack`, or the in-tree [bootstrap script]. See >> the accompanying >> [blog post] for details on migrating packaging to Hadrian. >> >> 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. >> >> Happy testing, >> >> - Ben >> >> >> [GHC proposal 0302]: >> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0302-cases.rst >> [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new >> [bootstrap script]: >> https://gitlab.haskell.org/ghc/ghc/-/blob/e2520df3fffa0cf22fb19c5fb872832d11c07d35/hadrian/bootstrap/README.md >> [Hadrian]: >> https://gitlab.haskell.org/ghc/ghc/-/blob/e2520df3fffa0cf22fb19c5fb872832d11c07d35/hadrian >> [release notes]: >> https://downloads.haskell.org/~ghc/9.4.1/docs/users_guide/9.4.1-notes.html >> [blog post]: >> https://www.haskell.org/ghc/blog/20220805-make-to-hadrian.html >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at well-typed.com Tue Aug 9 22:44:49 2022 From: ben at well-typed.com (Ben Gamari) Date: Tue, 09 Aug 2022 18:44:49 -0400 Subject: [Haskell-cafe] [ANNOUNCE] GHC 9.4.1 is now available In-Reply-To: <87v8r3wxo8.fsf@smart-cactus.org> References: <87v8r3wxo8.fsf@smart-cactus.org> Message-ID: <87edxpvxyr.fsf@smart-cactus.org> Ben Gamari writes: > The GHC developers are very pleased to announce the availability of GHC > 9.4.1. Binary distributions, source distributions, and documentation are > available at downloads.haskell.org: > > https://downloads.haskell.org/ghc/9.4.1 > Hi all, Due to an unfortunate packaging issue, the macOS binary distributions for 9.4.1 are not usable as uploaded. The problem is described in #21974, which also includes a small patch to mitigate the breakage. We will be releasing a 9.4.2 within the week fixing the issue. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From oleg.grenrus at iki.fi Tue Aug 9 22:48:35 2022 From: oleg.grenrus at iki.fi (Oleg Grenrus) Date: Wed, 10 Aug 2022 01:48:35 +0300 Subject: [Haskell-cafe] [ANNOUNCE] GHC 9.4.1 is now available In-Reply-To: <87edxpvxyr.fsf@smart-cactus.org> References: <87v8r3wxo8.fsf@smart-cactus.org> <87edxpvxyr.fsf@smart-cactus.org> Message-ID: Will GHC-9.4.2 contain any other changes? - Oleg On 10.8.2022 1.44, Ben Gamari wrote: > Ben Gamari writes: > >> The GHC developers are very pleased to announce the availability of GHC >> 9.4.1. Binary distributions, source distributions, and documentation are >> available at downloads.haskell.org: >> >> https://downloads.haskell.org/ghc/9.4.1 >> > Hi all, > > Due to an unfortunate packaging issue, the macOS binary > distributions for 9.4.1 are not usable as uploaded. The problem is > described in #21974, which also includes a small patch to mitigate the > breakage. We will be releasing a 9.4.2 within the week fixing the issue. > > Cheers, > > - Ben > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. From ben at smart-cactus.org Wed Aug 10 01:05:42 2022 From: ben at smart-cactus.org (Ben Gamari) Date: Tue, 09 Aug 2022 21:05:42 -0400 Subject: [Haskell-cafe] [ANNOUNCE] GHC 9.4.1 is now available In-Reply-To: References: <87v8r3wxo8.fsf@smart-cactus.org> <87edxpvxyr.fsf@smart-cactus.org> Message-ID: <87a68cx60d.fsf@smart-cactus.org> Oleg Grenrus writes: > Will GHC-9.4.2 contain any other changes? > Yes, at the moment it's looking like the release will contain: * the fixes for the BSD bindist installation bug * various documentation improvements * fixed FreeBSD CI support and, as a result, FreeBSD bindists * fixed ARMv7/Linux CI support, and, as a result, ARMv7 bindists * a new AArch64/Debian 11 CI job and associated bindist * a fix for #21987, fixing bootstrapping support with the make build system * likely a fix for haddock quick-fix support in the Hackage documentation (#21984) Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From ollie at ocharles.org.uk Wed Aug 10 07:11:03 2022 From: ollie at ocharles.org.uk (Oliver Charles) Date: Wed, 10 Aug 2022 08:11:03 +0100 Subject: [Haskell-cafe] Haskell SQL backends: How is data handed over? In-Reply-To: References: Message-ID: Hi Olaf, I can't speak for SQL in general, but if you're targeting PostgreSQL note that the hasql library uses a binary wire format. You'll need to use parameterized queries to benefit from this, but it would let you avoid encoding digits to ASCII. Ollie On Tue, 9 Aug 2022, at 8:34 PM, Olaf Klinke wrote: > Dear Café, > > I was discussing with a friend the fastest way to shovel data into a > SQL database after parsing the raw (textual) data with Haskell. I am > concerned about numeric conversion: In my experience parsing the file > structure is fast. The majority of the time is spent converting strings > of digits to numbers. I hoped that once Haskell has constructed a > Double, the backend driver can hand that binary value over to the > database engine. But Database.HDBC.Statement has a field > > orginalQuery :: String > > and HDBC has functions > > prepare :: Connection -> String -> IO Statement > run :: Connection -> String -> [SqlValue] -> IO Integer > > which makes me wonder whether the backend constructs a complete SQL > query statement in form of a string (including the SqlValues), and > hands that to the database driver to parse. Is that indeed so? > If yes, the numbers should never be parsed in the first place: The DB > will do that anyways. I might as well construct a new CSV file and let > the database do a bulk insert on that. The above is specific to the > HDBC backend. If there are other backends/frameworks that do the > marshalling more efficiently, please let me know. > > Thanks > Olaf > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Wed Aug 10 07:23:21 2022 From: allbery.b at gmail.com (Brandon Allbery) Date: Wed, 10 Aug 2022 03:23:21 -0400 Subject: [Haskell-cafe] Haskell SQL backends: How is data handed over? In-Reply-To: References:

Message-ID: That does make me wonder how many database interfaces use the scientific package for numbers, though. On Wed, Aug 10, 2022 at 3:11 AM Oliver Charles wrote: > > Hi Olaf, > > I can't speak for SQL in general, but if you're targeting PostgreSQL note that the hasql library uses a binary wire format. You'll need to use parameterized queries to benefit from this, but it would let you avoid encoding digits to ASCII. > > Ollie > > On Tue, 9 Aug 2022, at 8:34 PM, Olaf Klinke wrote: > > Dear Café, > > I was discussing with a friend the fastest way to shovel data into a > SQL database after parsing the raw (textual) data with Haskell. I am > concerned about numeric conversion: In my experience parsing the file > structure is fast. The majority of the time is spent converting strings > of digits to numbers. I hoped that once Haskell has constructed a > Double, the backend driver can hand that binary value over to the > database engine. But Database.HDBC.Statement has a field > > orginalQuery :: String > > and HDBC has functions > > prepare :: Connection -> String -> IO Statement > run :: Connection -> String -> [SqlValue] -> IO Integer > > which makes me wonder whether the backend constructs a complete SQL > query statement in form of a string (including the SqlValues), and > hands that to the database driver to parse. Is that indeed so? > If yes, the numbers should never be parsed in the first place: The DB > will do that anyways. I might as well construct a new CSV file and let > the database do a bulk insert on that. The above is specific to the > HDBC backend. If there are other backends/frameworks that do the > marshalling more efficiently, please let me know. > > Thanks > Olaf > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -- brandon s allbery kf8nh allbery.b at gmail.com From steven at steshaw.org Wed Aug 10 09:50:08 2022 From: steven at steshaw.org (Steven Shaw) Date: Wed, 10 Aug 2022 19:50:08 +1000 Subject: [Haskell-cafe] Haskell SQL backends: How is data handed over? In-Reply-To: References: Message-ID: Hi Olaf, It's unlikely that a HDBC database driver will reconstruct a String query and execute that against the database. The originalQuery is simply the one you originally provided to prepare the Statement. You probably want Statement's execute :: [SqlValue] -> IO Integer or executeMany :: [[SqlValue]] -> IO () The executeMany is intended to send a batch of prepared arguments to the database driver. However, I did note that the PostgreSQL driver for HDBC doesn't handle this efficiently. So, check the implementation for your specific backend. https://github.com/hdbc/hdbc-postgresql/blob/master/Database/HDBC/PostgreSQL/Statement.hsc#L207-L210 All that said, if you are doing a large bulk import, it could certainly be more efficient to use your database's facilities for doing bulk import. e.g. https://www.postgresql.org/docs/current/sql-copy.html You might also find that you are better off using an alternative to HDBC for your specific dbms, depending on the performance you require and whether executeMany is implemented efficiently in the HDBC driver for your dbms. -------------- next part -------------- An HTML attachment was scrubbed... URL: From olf at aatal-apotheke.de Wed Aug 10 15:22:18 2022 From: olf at aatal-apotheke.de (Olaf Klinke) Date: Wed, 10 Aug 2022 17:22:18 +0200 Subject: [Haskell-cafe] Haskell SQL backends: How is data handed over? Message-ID: <01fa9d3a5029a3295fe138e317232f23db0af511.camel@aatal-apotheke.de> Thanks all for the replies. It seems in my specific setup values are indeed passed as strings, see below. Oliver Charles wrote: > I can't speak for SQL in general, but if you're targeting PostgreSQL note that the hasql library uses a binary wire format. Good to know, thanks. It might be that for my specific case the database choice ship has sailed, unfortunately. Anthony Clayden wrote: > Going via CSV isn't really saving anything: the "bulk insert" is again > parsing those commas and the bits in between. (A dedicated SQL engine is > probably more efficient than Haskell's string handling.) That was what I was thinking, too: The bulk insert must also parse the numbers, so it would be kind of a waste to have Haskell parse the numbers, format them as Strings in the CSV just to have the SQL server parse them again. Brandon Allbery wrote: > More specifically, a query or DML statement is a string with ? > placeholders for values, which is "prepare"d to turn it into internal > format and then executed one or more times with values supplied. Sending the SQL statement as string is probably fine. I guess it depends on the specific HDBC backend whether run :: Connection -> String -> [SqlValue] -> IO Integer also sends the SqlValue arguments as String. Specifically, I chose persistent with HDBC-odbc backend because (1) We're talking to a Microsoft SQL server from a Linux client via unixODBC, (2) We chose Microsoft SQL to ensure trouble-free integration into the Microsoft office world, (3) I expect a web application will emerge from this, hence persistent because it integrates well with Yesod. In [HDBC-odbc] it is implemented in sqlBindValue, sqlBindParameter which contains CString -- ^ Parameter value pointer The actual value (if not a string) is converted to ByteString (using the Convertible class) and placed into the CString, it seems. The Convertible SqlValue Bytestring instance uses fromString and Convertible SqlValue String which in turn uses show [HDBC]. So yep, to ODBC the SqlValues are passed as Strings. HDBC-sqlite3 does the same. I opened [1]. Olaf [HDBC-odbc] https://hackage.haskell.org/package/HDBC-odbc-2.5.0.1/docs/src/Database-HDBC-ODBC-Statement.html [HDBC] https://hackage.haskell.org/package/HDBC-2.4.0.4/docs/src/Database.HDBC.SqlValue.html#line-262 [1] https://github.com/hdbc/hdbc/issues/56 From allbery.b at gmail.com Wed Aug 10 15:29:00 2022 From: allbery.b at gmail.com (Brandon Allbery) Date: Wed, 10 Aug 2022 11:29:00 -0400 Subject: [Haskell-cafe] Haskell SQL backends: How is data handed over? In-Reply-To: <01fa9d3a5029a3295fe138e317232f23db0af511.camel@aatal-apotheke.de> References: <01fa9d3a5029a3295fe138e317232f23db0af511.camel@aatal-apotheke.de> Message-ID: My observation about the "scientific" package is also relevant here: most DBMSes have a different notion of "number" than most programming languages, so unless there is specifically a binary number field type it is probably necessary to send it as a string of some variety. The "scientific" package abstracts over this for Haskell. On Wed, Aug 10, 2022 at 11:22 AM Olaf Klinke wrote: > > Thanks all for the replies. > It seems in my specific setup values are indeed passed as strings, see > below. > > Oliver Charles wrote: > > I can't speak for SQL in general, but if you're targeting PostgreSQL note that the hasql library uses a binary wire format. > Good to know, thanks. It might be that for my specific case the > database choice ship has sailed, unfortunately. > > Anthony Clayden wrote: > > Going via CSV isn't really saving anything: the "bulk insert" is again > > parsing those commas and the bits in between. (A dedicated SQL engine is > > probably more efficient than Haskell's string handling.) > That was what I was thinking, too: The bulk insert must also parse the > numbers, so it would be kind of a waste to have Haskell parse the > numbers, format them as Strings in the CSV just to have the SQL server > parse them again. > > Brandon Allbery wrote: > > More specifically, a query or DML statement is a string with ? > > placeholders for values, which is "prepare"d to turn it into internal > > format and then executed one or more times with values supplied. > Sending the SQL statement as string is probably fine. I guess it > depends on the specific HDBC backend whether > > run :: Connection -> String -> [SqlValue] -> IO Integer > > also sends the SqlValue arguments as String. > Specifically, I chose persistent with HDBC-odbc backend because > (1) We're talking to a Microsoft SQL server from a Linux client via > unixODBC, > (2) We chose Microsoft SQL to ensure trouble-free integration into the > Microsoft office world, > (3) I expect a web application will emerge from this, hence persistent > because it integrates well with Yesod. > > In [HDBC-odbc] it is implemented in sqlBindValue, sqlBindParameter > which contains > CString -- ^ Parameter value pointer > The actual value (if not a string) is converted to ByteString (using > the Convertible class) and placed into the CString, it seems. The > Convertible SqlValue Bytestring instance uses fromString and > Convertible SqlValue String which in turn uses show [HDBC]. > So yep, to ODBC the SqlValues are passed as Strings. HDBC-sqlite3 does > the same. I opened [1]. > > Olaf > > [HDBC-odbc] https://hackage.haskell.org/package/HDBC-odbc-2.5.0.1/docs/src/Database-HDBC-ODBC-Statement.html > [HDBC] https://hackage.haskell.org/package/HDBC-2.4.0.4/docs/src/Database.HDBC.SqlValue.html#line-262 > [1] https://github.com/hdbc/hdbc/issues/56 > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -- brandon s allbery kf8nh allbery.b at gmail.com From olf at aatal-apotheke.de Thu Aug 11 19:36:50 2022 From: olf at aatal-apotheke.de (Olaf Klinke) Date: Thu, 11 Aug 2022 21:36:50 +0200 Subject: [Haskell-cafe] Haskell SQL backends: How is data handed over? Message-ID: > My observation about the "scientific" package is also relevant here: > most DBMSes have a different notion of "number" than most programming > languages, so unless there is specifically a binary number field type > it is probably necessary to send it as a string of some variety. The > "scientific" package abstracts over this for Haskell. You mean that formatting a Scientific number as String is more efficient than formatting an Integer/Double in its usual representation? How about parsing? In most parsing libraries I've seen [1,2,3] the following code transforms a string of digits to an integer. import Data.Char (ord) import Data.Foldable (foldl') -- The parser ensures only digit Chars -- are passed to this function. fromDigit :: Num a => Char -> a fromDigit = let z = ord '0' in \digit -> fromIntegral (ord digit - z) appendDigit :: Num a => a -> Char -> a appendDigit x d = 10 * x + fromDigit d digitsToNum :: Num a => [Char] -> a digitsToNum = foldl' appendDigit 0 If in addition to 'show' the function prependDigit (and its foldr cousin for digits behind the floating point) were particularly efficient for Scientific [*], that would indeed make a strong case for using Scientific in parsing and (SQL-)database applications. Olaf [1] https://hackage.haskell.org/package/parsec-3.1.15.1/docs/src/Text.Parsec.Token.html#local-6989586621679060535 [2] https://hackage.haskell.org/package/megaparsec-9.2.1/docs/src/Text.Megaparsec.Char.Lexer.html#decimal_ [3] https://hackage.haskell.org/package/attoparsec-0.14.4/docs/src/Data.Attoparsec.Text.html#decimal [*] This seems not to be the case currently: The Num instance is implemented as Scientific c1 e1 * Scientific c2 e2 = Scientific (c1 * c2) (e1 + e2) Would it be a bad idea to add special cases for numbers of the form Scientific 1 e? It penalizes all multiplications with a pattern match. From allbery.b at gmail.com Thu Aug 11 19:45:33 2022 From: allbery.b at gmail.com (Brandon Allbery) Date: Thu, 11 Aug 2022 15:45:33 -0400 Subject: [Haskell-cafe] Haskell SQL backends: How is data handed over? In-Reply-To: References: Message-ID: Let me try this again. Database backends generally use the scientific package to represent numbers, because databases do not represent numbers as Haskell Int / C (int) or even Haskell Integers (unless you mean something like Data.Fixed). A database number typically has a number of decimal digits and a precision again specified as decimal digits. (ex. NUMERIC(9, 2)) It is not floating point. The scientific package, to fit such applications (including that of JSON), stores numbers as ASCII digits because they are so represented (as decimal digits and decimal precision), not as machine numbers. Accordingly, these numbers are stored and transmitted as decimal digits, not as the sort of binary numbers you might expect. On Thu, Aug 11, 2022 at 3:36 PM Olaf Klinke wrote: > > > My observation about the "scientific" package is also relevant here: > > most DBMSes have a different notion of "number" than most programming > > languages, so unless there is specifically a binary number field type > > it is probably necessary to send it as a string of some variety. The > > "scientific" package abstracts over this for Haskell. > > You mean that formatting a Scientific number as String is more > efficient than formatting an Integer/Double in its usual > representation? How about parsing? In most parsing libraries I've seen > [1,2,3] the following code transforms a string of digits to an integer. > > import Data.Char (ord) > import Data.Foldable (foldl') > > -- The parser ensures only digit Chars > -- are passed to this function. > fromDigit :: Num a => Char -> a > fromDigit = let > z = ord '0' > in \digit -> fromIntegral (ord digit - z) > > appendDigit :: Num a => a -> Char -> a > appendDigit x d = 10 * x + fromDigit d > > digitsToNum :: Num a => [Char] -> a > digitsToNum = foldl' appendDigit 0 > > If in addition to 'show' the function prependDigit (and its foldr > cousin for digits behind the floating point) were particularly > efficient for Scientific [*], that would indeed make a strong case for > using Scientific in parsing and (SQL-)database applications. > > Olaf > > [1] https://hackage.haskell.org/package/parsec-3.1.15.1/docs/src/Text.Parsec.Token.html#local-6989586621679060535 > [2] https://hackage.haskell.org/package/megaparsec-9.2.1/docs/src/Text.Megaparsec.Char.Lexer.html#decimal_ > [3] https://hackage.haskell.org/package/attoparsec-0.14.4/docs/src/Data.Attoparsec.Text.html#decimal > [*] This seems not to be the case currently: The Num instance is implemented as > > Scientific c1 e1 * Scientific c2 e2 = > Scientific (c1 * c2) (e1 + e2) > > Would it be a bad idea to add special cases for numbers of the form > Scientific 1 e? It penalizes all multiplications with a pattern match. > -- brandon s allbery kf8nh allbery.b at gmail.com From allbery.b at gmail.com Thu Aug 11 19:57:03 2022 From: allbery.b at gmail.com (Brandon Allbery) Date: Thu, 11 Aug 2022 15:57:03 -0400 Subject: [Haskell-cafe] Haskell SQL backends: How is data handed over? In-Reply-To: References: Message-ID: Also let me say that databases *may* optimize this or allow use of native types, with the risk of truncating or expecting a larger type than the programmer expects. Scientific avoids this at the price of using the textual representations the target expects. On Thu, Aug 11, 2022, 15:45 Brandon Allbery wrote: > Let me try this again. > > Database backends generally use the scientific package to represent > numbers, because databases do not represent numbers as Haskell Int / C > (int) or even Haskell Integers (unless you mean something like > Data.Fixed). A database number typically has a number of decimal > digits and a precision again specified as decimal digits. (ex. > NUMERIC(9, 2)) It is not floating point. > > The scientific package, to fit such applications (including that of > JSON), stores numbers as ASCII digits because they are so represented > (as decimal digits and decimal precision), not as machine numbers. > > Accordingly, these numbers are stored and transmitted as decimal > digits, not as the sort of binary numbers you might expect. > > On Thu, Aug 11, 2022 at 3:36 PM Olaf Klinke wrote: > > > > > My observation about the "scientific" package is also relevant here: > > > most DBMSes have a different notion of "number" than most programming > > > languages, so unless there is specifically a binary number field type > > > it is probably necessary to send it as a string of some variety. The > > > "scientific" package abstracts over this for Haskell. > > > > You mean that formatting a Scientific number as String is more > > efficient than formatting an Integer/Double in its usual > > representation? How about parsing? In most parsing libraries I've seen > > [1,2,3] the following code transforms a string of digits to an integer. > > > > import Data.Char (ord) > > import Data.Foldable (foldl') > > > > -- The parser ensures only digit Chars > > -- are passed to this function. > > fromDigit :: Num a => Char -> a > > fromDigit = let > > z = ord '0' > > in \digit -> fromIntegral (ord digit - z) > > > > appendDigit :: Num a => a -> Char -> a > > appendDigit x d = 10 * x + fromDigit d > > > > digitsToNum :: Num a => [Char] -> a > > digitsToNum = foldl' appendDigit 0 > > > > If in addition to 'show' the function prependDigit (and its foldr > > cousin for digits behind the floating point) were particularly > > efficient for Scientific [*], that would indeed make a strong case for > > using Scientific in parsing and (SQL-)database applications. > > > > Olaf > > > > [1] > https://hackage.haskell.org/package/parsec-3.1.15.1/docs/src/Text.Parsec.Token.html#local-6989586621679060535 > > [2] > https://hackage.haskell.org/package/megaparsec-9.2.1/docs/src/Text.Megaparsec.Char.Lexer.html#decimal_ > > [3] > https://hackage.haskell.org/package/attoparsec-0.14.4/docs/src/Data.Attoparsec.Text.html#decimal > > [*] This seems not to be the case currently: The Num instance is > implemented as > > > > Scientific c1 e1 * Scientific c2 e2 = > > Scientific (c1 * c2) (e1 + e2) > > > > Would it be a bad idea to add special cases for numbers of the form > > Scientific 1 e? It penalizes all multiplications with a pattern match. > > > > > -- > brandon s allbery kf8nh > allbery.b at gmail.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From olf at aatal-apotheke.de Thu Aug 11 20:00:31 2022 From: olf at aatal-apotheke.de (Olaf Klinke) Date: Thu, 11 Aug 2022 22:00:31 +0200 Subject: [Haskell-cafe] Haskell SQL backends: How is data handed over? In-Reply-To: References: Message-ID: On Thu, 2022-08-11 at 15:45 -0400, Brandon Allbery wrote: > Let me try this again. > > Database backends generally use the scientific package to represent > numbers, because databases do not represent numbers as Haskell Int / C > (int) or even Haskell Integers (unless you mean something like > Data.Fixed). A database number typically has a number of decimal > digits and a precision again specified as decimal digits. (ex. > NUMERIC(9, 2)) It is not floating point. Indeed, one could regard Scientific as the union of all types NUMERIC(x,y) for x,y natural numbers. > > The scientific package, to fit such applications (including that of > JSON), stores numbers as ASCII digits The coefficient is a machine number, isn't it? So I'd not call it ASCII digits. Hence my proposal to investigate optimizing + and *. But probably this has been considered long ago. > because they are so represented > (as decimal digits and decimal precision), not as machine numbers. > > Accordingly, these numbers are stored and transmitted as decimal > digits, not as the sort of binary numbers you might expect. > > On Thu, Aug 11, 2022 at 3:36 PM Olaf Klinke wrote: > > > My observation about the "scientific" package is also relevant here: > > > most DBMSes have a different notion of "number" than most programming > > > languages, so unless there is specifically a binary number field type > > > it is probably necessary to send it as a string of some variety. The > > > "scientific" package abstracts over this for Haskell. > > > > You mean that formatting a Scientific number as String is more > > efficient than formatting an Integer/Double in its usual > > representation? How about parsing? In most parsing libraries I've seen > > [1,2,3] the following code transforms a string of digits to an integer. > > > > import Data.Char (ord) > > import Data.Foldable (foldl') > > > > -- The parser ensures only digit Chars > > -- are passed to this function. > > fromDigit :: Num a => Char -> a > > fromDigit = let > > z = ord '0' > > in \digit -> fromIntegral (ord digit - z) > > > > appendDigit :: Num a => a -> Char -> a > > appendDigit x d = 10 * x + fromDigit d > > > > digitsToNum :: Num a => [Char] -> a > > digitsToNum = foldl' appendDigit 0 > > > > If in addition to 'show' the function prependDigit (and its foldr > > cousin for digits behind the floating point) were particularly > > efficient for Scientific [*], that would indeed make a strong case for > > using Scientific in parsing and (SQL-)database applications. > > > > Olaf > > > > [1] https://hackage.haskell.org/package/parsec-3.1.15.1/docs/src/Text.Parsec.Token.html#local-6989586621679060535 > > [2] https://hackage.haskell.org/package/megaparsec-9.2.1/docs/src/Text.Megaparsec.Char.Lexer.html#decimal_ > > [3] https://hackage.haskell.org/package/attoparsec-0.14.4/docs/src/Data.Attoparsec.Text.html#decimal > > [*] This seems not to be the case currently: The Num instance is implemented as > > > > Scientific c1 e1 * Scientific c2 e2 = > > Scientific (c1 * c2) (e1 + e2) > > > > Would it be a bad idea to add special cases for numbers of the form > > Scientific 1 e? It penalizes all multiplications with a pattern match. > > > > From a.pelenitsyn at gmail.com Thu Aug 11 23:58:05 2022 From: a.pelenitsyn at gmail.com (Artem Pelenitsyn) Date: Thu, 11 Aug 2022 19:58:05 -0400 Subject: [Haskell-cafe] Just released: cabal 3.8.1.0 In-Reply-To: References: Message-ID: ---------- Forwarded message --------- From: Mikolaj Konarski Date: Thu, Aug 11, 2022 at 7:05 PM Subject: Just released: cabal 3.8.1.0 To: Here's the happy news. :) Let me copy below the contents of the announcement from https://discourse.haskell.org/t/just-released-cabal-3-8-1-0/4920 but, additionally, on this mailing list I'd like to personally thank Emily and Oleg who, among all the giants on whose shoulders we stand, have most directly affected 3.8.1.0 with their hearts and wisdom. Haskell community owes you big time. --- I’m proud to announce 3.8.1.0 version of Cabal the library and cabal-install the tool. It’s the fruit of concerted effort of innumerous collaborators, from users, through developers, to mentors, caretakers and administrators of our linked community and infrastructure sections. You, people, rock. This version works with the just released GHC 9.4.1 (in fact, for Windows it’s probably necessary) and is already available form GHCup and other channels. More technical details, APIs, changelogs and regressions can be found at Release cabal v3.8.1.0 · haskell/cabal · GitHub. The release is huge, so let me mention only a few random highlights: public/private sublibraries are fully supported and no longer experimental (6. Package Description — Cabal 3.8.1.0 User's Guide) you can now put in your cabal.project something like import: https://www.stackage.org/lts-18.5/cabal.config and it works (7. cabal.project Reference — Cabal 3.8.1.0 User's Guide) new Cabal-syntax and cabal-install-solver packages have been split off there’s no more confusion of compiler options for the local code and for the dependencies (https://github.com/haskell/cabal/pull/7973) one can now define code generators in test stanzas, which is one more principled step away from Custom Setups (https://github.com/haskell/cabal/pull/7688) Cabal badly needs your feedback and your contributions. Please keep them coming. _______________________________________________ cabal-devel mailing list cabal-devel at haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From anthony.d.clayden at gmail.com Fri Aug 12 00:29:46 2022 From: anthony.d.clayden at gmail.com (Anthony Clayden) Date: Fri, 12 Aug 2022 12:29:46 +1200 Subject: [Haskell-cafe] Haskell SQL backends: How is data handed over? Message-ID: > @Olaf You mean that formatting a Scientific number as String is more efficient > than formatting an Integer/Double in its usual representation? > How about parsing? I'm not going to defend the 'efficiency' of Haskell's String formatting/parsing, but ... What is your evidence that number/String is a concern here? It's all happening in-memory. Whereas sending whatever to SQL then needs putting it to disk, which is orders-of-magnitude slower. (Or is this an in-memory database?) This thread has already devoted more cycles to speculation than you're going to reclaim through number formatting, methinks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ietf-dane at dukhovni.org Fri Aug 12 02:22:46 2022 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Thu, 11 Aug 2022 22:22:46 -0400 Subject: [Haskell-cafe] Haskell SQL backends: How is data handed over? In-Reply-To: References:

Message-ID: On Tue, Aug 09, 2022 at 04:53:58PM -0400, Brandon Allbery wrote: > More specifically, a query or DML statement is a string with ? > placeholders for values, which is "prepare"d to turn it into internal > format and then executed one or more times with values supplied. The values are serialised, but typically not as strings, avoiding both a performance penalty and potential SQL-injection issues. -- Viktor. From olf at aatal-apotheke.de Fri Aug 12 20:37:59 2022 From: olf at aatal-apotheke.de (Olaf Klinke) Date: Fri, 12 Aug 2022 22:37:59 +0200 Subject: [Haskell-cafe] Haskell SQL backends: How is data handed over? Message-ID: Anthony Clayden wrote: > What is your evidence that number/String is a concern here? It's all > happening in-memory. > > Whereas sending whatever to SQL then needs putting it to disk, which is > orders-of-magnitude slower. (Or is this an in-memory database?) > > This thread has already devoted more cycles to speculation than you're > going to reclaim through number formatting, methinks. Very good point. I'm fairly new to SQL, have a solution that works and started to wonder how efficient it is. Since the way data is passed to and from the DB engine affects every database interaction, for every user, I thought it might be worthwile investigating. And as I said earlier, profiling other code has proved that number parsing can make up a significant portion of a data-heavy program's CPU time. Thus it's not speculation entirely. Olaf From ifl21.publicity at gmail.com Mon Aug 15 06:42:36 2022 From: ifl21.publicity at gmail.com (Pieter Koopman) Date: Mon, 15 Aug 2022 01:42:36 -0500 Subject: [Haskell-cafe] IFL22: Early registration deadline August 15th Message-ID: *IFL 2022Frederiksberg Campus of Faculty of Science, UCPH, CopenhagenAugust 31s-September 2nd, 2022* *Early registration deadline: August 15th AoE * *See **https://ifl22.github.io/* * for more information.* *CALL FOR PARTICIPATION:* The 34th Symposium on Implementation and Application of Functional Languages (IFL 2022) Copenhagen, August 31st-September 2nd, 2022 *Important dates* Submission deadline of draft papers August 8th, 2022 (EXPIRED) Notification of acceptance August 9th, 2022 (EXPIRED) Early registration deadline August 15th, 2022 (AoE) Late registration deadline August 31st, 2022, 12:59 CET (UTC+2) IFL Symposium August 31st - September 2nd, 2022 (We-Fr) *Scope* The goal of IFL is to bring together researchers and developers actively engaged in the implementation and application of functional programming languages and function-oriented programming. IFL 2022 is held in beautiful Copenhagen, Denmark and is 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 programming languages and function-oriented programming. *Invited speakers* IFL 2022 is pleased to announce keynote talks by the following three invited speakers: * Peter Sestoft, Professor, Head of Department, IT University of Copenhagen, Denmark: "Abstract machines and functional language implementation" * Lennart Augustsson, Principal Programmer, Epic Games: "Verse - a new functional-logic language" * Thomas Gazagnaire, Chief Technology Officer and co-founder, Tarides: "Talk title to be announced" *Venue and registration* The symposium will be held physically on the Frederiksberg Campus of the Faculty of Science at the University of Copenhagen. Days 1 and 2 (August 31st and September 1st) will be in meeting room A2-84.01 at Thorvaldsensvej 40. Day 3 (September 2nd) will be in the Celebration Auditorium at Bülowsvej 17. For registration and fees, please consult the symposium web site at https://ifl22.github.io/. Please notice that the early registration date is August 15, 2022 (AoE). *Accepted papers* * Asynchronous Shared Data Sources. Mart Lubbers, Haye Böhm, Pieter Koopman and Rinus Plasmeijer. * Heuristics-based Type Error Diagnosis for Haskell: the case of type families. Niels Kwadijk and Jurriaan Hage. * Verified Technology Mapping in an Agda DSL for Circuit Design. João Paulo Pizani Flor and Wouter Swierstra. * Creating Interactive Visualizations of TopHat Programs. Mark Gerarts, Marc de Hoog, Nico Naus and Tim Steenvoorden. * An SQL Frontend on top of OCaml for Data Analysis. Yan Dong, Yahui Song and Wei-Ngan Chin. * A Structure Editor with Type-Safe Copy/Paste. Hans Hüttel, Christoffer Lind Andersen, Nana Gjerulf Sandberg, Anja Elisasen Lumholtz Nielsen and Peter Mikkelsen. * How to fold and color a map: Comparing Use-Cases of Tree-Fold vs Fold-Left. Jim Newton. * Compiling a functional array language with non-semantic memory information. Philip Munksgaard, Cosmin Oancea and Troels Henriksen. * Systems of partial values and their applications in Haskell. Natasha England-Elbro. * First-Class Data Types in Shallow Embedded Domain-Specific Languages using Metaprogramming. Mart Lubbers, Pieter Koopman and Rinus Plasmeijer. * Set-theoretic Types for Erlang. Albert Schimpf, Stefan Wehr and Annette Bieniusa. * Strongly-Typed Multi-View Stack-Based Computations. Pieter Koopman and Mart Lubbers. * Ztrategic: Strategic Programming with Zippers. José Nuno Macedo, Emanuel Rodrigues, Marcos Viera and João Saraiva. * Higher-ranked region inference for polymorphic, lazy languages. Ivo Gabe de Wolff and Jurriaan Hage. * Jeopardy: An invertible functional programming language. Joachim Kristensen, Robin Kaarsgaard and Michael Kirkedal Thomsen. * The Foil: Capture-Avoiding Substitution With No Sharp Edges. Dougal Maclaurin, Alexey Radul and Adam Paszke. * Verified Causal Broadcast with Liquid Haskell. Patrick Redmond, Gan Shen, Niki Vazou and Lindsey Kuper. * Towards Inversion of Tail-recursive Term Rewriting Systems. Maria Bendix Mikkelsen, Robert Glück and Maja Hanne Kirkeby. * A Confluence and Termination Checker for Haskell Rewrite Rules. Makoto Hamana. * On Generating Out-Of-Core GPU Code for Multi-Dimensional Array Operations. Patrick van Beurden and Sven-Bodo Scholz. * Compiling Haskell for Energy Efficiency: Analysis of Individual Transformations. Bernardo Santos, João Fernandes, Maja Kirkeby and Alberto Pardo. *Post-symposium peer review * Following IFL tradition, IFL 2022 will use a post-symposium review process to produce the formal proceedings. Before the symposium authors submit draft papers. These draft papers have been screened by the program chair 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. Notice that it is a requirement that draft papers that are accepted for presentation be presented physically at the symposium. After the symposium the authors are invited to submit a full paper, incorporating feedback from discussions at the symposium. Work submitted to IFL may not be simultaneously submitted to other venues; submissions must adhere to ACM SIGPLAN's republication policy. The program committee will evaluate these submissions according to their correctness, novelty, originality, relevance, significance, and clarity, and will thereby determine whether the paper will be accepted or rejected for the formal proceedings. Papers that are accepted for the formal proceedings are published in the International Conference Proceedings Series of the ACM Digital Library, as in previous years. *Peter Landin Prize* The Peter Landin Prize is awarded to the best paper presented at the symposium every year. The honored 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. *Sponsors* IFL 2022 is financially supported by - Meta (Silver sponsor), - Well-typed (Bronze sponsor), - Funktionelle Københavnere (Bronze sponsor), and - University of Copenhagen (administrative support, host). *Organisation* General chair Fritz Henglein, University of Copenhagen Program chair Martin Elsman, University of Copenhagen Communications chair Troels Henriksen, University of Copenhagen *Program committee* Laura M. Castro Universidade da Coruña, Spain David Christiansen Haskell Foundation Martin Elsman University of Copenhagen, Denmark (chair) Matthew Fluet Rochester Institute of Technology, USA Clemens Grelck Universiteit van Amsterdam, The Netherlands Zhenjiang Hu Peking University, China Robin Kaarsgaard University of Edinburgh, Scotland Gabriele Keller Utrecht University, The Netherlands Oleg Kiselyov Tohoku University, Japan Neil Mitchell Facebook Stefan Monnier Universite de Montreal, Canada Magnus Myreen Chalmers University, Sweden Cyrus Omar University of Michigan, USA Romain Péchoux University of Lorraine, Inria, France Rinus Plasmeijer Radboud University, The Netherlands Morten Rhiger Roskilde University, Denmark Peter van Roy Catholic University of Louvain, Belgium Olin Shivers Northeastern University, USA Peter Thiemann University of Freiburg, Germany Marcos Viera Universidad de la República, Uruguay Meng Wang University of Bristol, UK [image: beacon] -------------- next part -------------- An HTML attachment was scrubbed... URL: From georg+haskell at schaathun.net Tue Aug 16 19:08:50 2022 From: georg+haskell at schaathun.net (Hans Georg Schaathun) Date: Tue, 16 Aug 2022 21:08:50 +0200 Subject: [Haskell-cafe] Web server with dynamic data Message-ID: Hi, I have been fiddling with this idea for some time, and I wonder if this may be the right place to ask a rather probing question!? It has been some years since my last visit to the list. I have been searching for examples using functional reactive programming to make web servers, but this proves surprisingly hard to find. I found the netwire library, but given that the last update was 2011 I am not sure I want to risk that ... So maybe I was asking the wrong question. I have a rather complex system of RDF Graphs (using Swish), with reasoners making derived graphs, and updates being made only on the original graphs. There are multiple constituent graphs to avoid having to recompute everything upon update. Now I was thinking that this looks like a typical case for FRP, with each graph a Behaviour, recomputing derived graph only when the source behaviour changes. I am not sure if I am right. Any opinions? The second part of this is the web server to allow queries (read and update) to the RDF Graphs. The first prototype uses Scotty with STM for storage, but when I add more constituent graphs, I really do not want an update to block access to other constituent graphs, which is what I thought I could avoid in an FRP model. Without much experience writing interactive stuff in Haskell, I cannot figure out how to wire the interaction between Scotty and either netwire or banana which are the two FRP libraries I have tried to comprehend. Are there any examples out there to look at? I am not really committed to any library or paradigm, except for RDF and Swish, so any ideas will be welcome, even pointing me away from everything I thought I needed ... Thanks for reading, :-- George From nadine.and.henry at pobox.com Thu Aug 18 04:37:47 2022 From: nadine.and.henry at pobox.com (Henry Laxen) Date: Wed, 17 Aug 2022 21:37:47 -0700 Subject: [Haskell-cafe] Ambiguous type variable with lenses Message-ID: <871qtexj38.fsf@pobox.com> -- run this with: ghci -package microlens-platform T7.hs {-# LANGUAGE TemplateHaskell #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE AllowAmbiguousTypes #-} {-# LANGUAGE FlexibleInstances #-} module T7 where import Lens.Micro.Platform type Lenstype f a b = (b -> f b) -> a -> f a data A = A { _a1 :: Int , _a2 :: String} deriving (Show) $(makeLenses ''A) class B a where lensB1 :: (Functor f) => Lenstype f a Int lensB2 :: (Functor f) => Lenstype f a String instance B A where lensB1 = a1 lensB2 = a2 xa = A 1 "one" ya1 = xa ^. a1 ya2 = xa ^. lensB1 test1 = ya1 == ya2 -- True -- But I would like to use a type variable for the String field of A data C b = C { _c1 :: Int , _c2 :: b} deriving (Show) $(makeLenses ''C) -- So next I define: class D a b where -- Need MultiParamTypeClasses here lensD1 :: (Functor f) => Lenstype f a Int -- Need AllowAmbiguousTypes here lensD2 :: (Functor f) => Lenstype f a b instance D (C b) b where -- Need FlexibleInstances here lensD1 = c1 lensD2 = c2 xc1 = C 1 "one" :: C String xc2 = C 1 'o' :: C Char yc1 = xc1 ^. c1 :: Int yc2 = xc2 ^. c1 :: Int test2 = yc1 == yc2 -- True -- All good until here. Now the trouble begins. If you uncomment the next two lines you get: -- zc1 = xc1 ^. lensD1 :: Int -- zc2 = xc2 ^. lensD1 :: Int -- T7.hs:62:14-19: error: -- • Ambiguous type variable ‘b1’ arising from a use of ‘lensD1’ -- prevents the constraint ‘(D (C String) b1)’ from being solved. -- Probable fix: use a type annotation to specify what ‘b1’ should be. -- These potential instance exist: -- instance D (C b) b -- -- Defined at /home/henry/haskell/dev/T7.hs:44:10 -- • In the second argument of ‘(^.)’, namely ‘lensD1’ -- In the expression: xc1 ^. lensD1 :: Int -- In an equation for ‘zc1’: zc1 = xc1 ^. lensD1 :: Int -- | -- 62 | zc1 = xc1 ^. lensD1 :: Int -- | ^^^^^^ -- T7.hs:63:14-19: error: -- • Ambiguous type variable ‘b0’ arising from a use of ‘lensD1’ -- prevents the constraint ‘(D (C Char) b0)’ from being solved. -- Probable fix: use a type annotation to specify what ‘b0’ should be. -- These potential instance exist: -- instance D (C b) b -- -- Defined at /home/henry/haskell/dev/T7.hs:44:10 -- • In the second argument of ‘(^.)’, namely ‘lensD1’ -- In the expression: xc2 ^. lensD1 :: Int -- In an equation for ‘zc2’: zc2 = xc2 ^. lensD1 :: Int -- | -- 63 | zc2 = xc2 ^. lensD1 :: Int -- | ^^^^^^ -- But zc1 and zc2 don't care what is in the second slot. I would -- like to store different types in the second slot of C, but the -- first slot of C will always be an Int. Is there any way to -- manipulate the first slot alone? I got some compiler "suggestions" -- concernting RankNTypes and QuantifiedConstraints but nothing I -- tried ended up working. -- Thanks in advance for your help. -- Henry Laxen From keith.wygant at gmail.com Thu Aug 18 15:24:45 2022 From: keith.wygant at gmail.com (Keith) Date: Thu, 18 Aug 2022 15:24:45 +0000 Subject: [Haskell-cafe] Ambiguous type variable with lenses In-Reply-To: <871qtexj38.fsf@pobox.com> References: <871qtexj38.fsf@pobox.com> Message-ID: I haven't tested this out, but have you tried putting a functional dependency on the class(| a -> b)? Could also put each method in its own class. -- Sent from my phone with K-9 Mail. On 18 August 2022 04:37:47 UTC, Henry Laxen wrote: >-- run this with: ghci -package microlens-platform T7.hs >{-# LANGUAGE TemplateHaskell #-} >{-# LANGUAGE TypeFamilies #-} >{-# LANGUAGE MultiParamTypeClasses #-} >{-# LANGUAGE AllowAmbiguousTypes #-} >{-# LANGUAGE FlexibleInstances #-} > >module T7 where > >import Lens.Micro.Platform > >type Lenstype f a b = (b -> f b) -> a -> f a > >data A = A { _a1 :: Int , _a2 :: String} deriving (Show) >$(makeLenses ''A) > >class B a where > lensB1 :: (Functor f) => Lenstype f a Int > lensB2 :: (Functor f) => Lenstype f a String > >instance B A where > lensB1 = a1 > lensB2 = a2 > >xa = A 1 "one" >ya1 = xa ^. a1 >ya2 = xa ^. lensB1 > >test1 = ya1 == ya2 -- True > >-- But I would like to use a type variable for the String field of A > >data C b = C { _c1 :: Int , _c2 :: b} deriving (Show) >$(makeLenses ''C) > >-- So next I define: > >class D a b where -- Need MultiParamTypeClasses here > lensD1 :: (Functor f) => Lenstype f a Int -- Need AllowAmbiguousTypes here > lensD2 :: (Functor f) => Lenstype f a b > >instance D (C b) b where -- Need FlexibleInstances here > lensD1 = c1 > lensD2 = c2 > >xc1 = C 1 "one" :: C String >xc2 = C 1 'o' :: C Char > >yc1 = xc1 ^. c1 :: Int >yc2 = xc2 ^. c1 :: Int > >test2 = yc1 == yc2 -- True > >-- All good until here. Now the trouble begins. If you uncomment the next two lines you get: > >-- zc1 = xc1 ^. lensD1 :: Int >-- zc2 = xc2 ^. lensD1 :: Int > >-- T7.hs:62:14-19: error: >-- • Ambiguous type variable ‘b1’ arising from a use of ‘lensD1’ >-- prevents the constraint ‘(D (C String) b1)’ from being solved. >-- Probable fix: use a type annotation to specify what ‘b1’ should be. >-- These potential instance exist: >-- instance D (C b) b >-- -- Defined at /home/henry/haskell/dev/T7.hs:44:10 >-- • In the second argument of ‘(^.)’, namely ‘lensD1’ >-- In the expression: xc1 ^. lensD1 :: Int >-- In an equation for ‘zc1’: zc1 = xc1 ^. lensD1 :: Int >-- | >-- 62 | zc1 = xc1 ^. lensD1 :: Int >-- | ^^^^^^ > >-- T7.hs:63:14-19: error: >-- • Ambiguous type variable ‘b0’ arising from a use of ‘lensD1’ >-- prevents the constraint ‘(D (C Char) b0)’ from being solved. >-- Probable fix: use a type annotation to specify what ‘b0’ should be. >-- These potential instance exist: >-- instance D (C b) b >-- -- Defined at /home/henry/haskell/dev/T7.hs:44:10 >-- • In the second argument of ‘(^.)’, namely ‘lensD1’ >-- In the expression: xc2 ^. lensD1 :: Int >-- In an equation for ‘zc2’: zc2 = xc2 ^. lensD1 :: Int >-- | >-- 63 | zc2 = xc2 ^. lensD1 :: Int >-- | ^^^^^^ > > >-- But zc1 and zc2 don't care what is in the second slot. I would >-- like to store different types in the second slot of C, but the >-- first slot of C will always be an Int. Is there any way to >-- manipulate the first slot alone? I got some compiler "suggestions" >-- concernting RankNTypes and QuantifiedConstraints but nothing I >-- tried ended up working. > >-- Thanks in advance for your help. >-- Henry Laxen >_______________________________________________ >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 nadine.and.henry at pobox.com Thu Aug 18 16:27:05 2022 From: nadine.and.henry at pobox.com (Henry Laxen) Date: Thu, 18 Aug 2022 09:27:05 -0700 Subject: [Haskell-cafe] Ambiguous type variable with lenses In-Reply-To: References: <871qtexj38.fsf@pobox.com> Message-ID: <87k075sejq.fsf@pobox.com> Thank you Keith, that was the "incantation" I was looking for. Best wishes, Henry Laxen Keith writes: > I haven't tested this out, but have you tried putting a functional dependency on the class(| a -> b)? Could also put each method in its own class. > -- > Sent from my phone with K-9 Mail. > From andreas.abel at ifi.lmu.de Fri Aug 19 20:25:10 2022 From: andreas.abel at ifi.lmu.de (Andreas Abel) Date: Fri, 19 Aug 2022 22:25:10 +0200 Subject: [Haskell-cafe] [ANN] cabal-clean 0.2 In-Reply-To: References: Message-ID: cabal-clean 0.2 has just been released! https://hackage.haskell.org/package/cabal-clean-0.2.20220819 New: - Also removes builds by GHCs which are no longer in the PATH (so, arepresumably uninstalled). - Fixed to work also under Windows. On 2021-09-24 19:09, Andreas Abel wrote: > === Wondering where your disk space goes with too many Haskell projects > compiled with too many GHC versions? === > > https://hackage.haskell.org/package/cabal-clean > https://github.com/andreasabel/cabal-clean > > `cabal-clean` is a small executable that removes outdated cabal build > artifacts from `dist-newstyle`. > > A build tree is considered outdated if there is one with either > > - a newer version of the package you are building, or > - a newer minor version of the GHC compiler. > > In contrast to `cabal clean`, the tool `cabal-clean` retains the latest > build trees for each GHC major version. Thus, it is geared towards > multi-GHC development. > > Example: (self-applied to cabal-clean's build directory) > > --- 3.7M ghc-8.8.4 /cabal-clean-0.1.20210815 > --- 3.5M ghc-8.10.6/cabal-clean-0.1.20210815 > --- 3.7M ghc-9.0.1 /cabal-clean-0.1.20210815 > --- 3.5M ghc-8.10.6/cabal-clean-0.1.20210924 > +++ 3.6M ghc-8.10.7/cabal-clean-0.1.20210924 > +++ 3.7M ghc-9.0.1 /cabal-clean-0.1.20210924 > > The directories prefixed with --- will be deleted, the ones with +++ > retained. > > Disclaimers: > > 1. cabal-clean does not check whether deletion will cause dangling > references like broken symlinks etc. (Could happen if you created a > symlink to an executable that resides in one of the deleted build > directories.) > > 2. cabal-clean does not read nor utilize information from the .cabal > file. > > 3. Calls `du` ("disk usage"), so, might not work on Windows. > > Enjoy, > Andreas > _______________________________________________ > 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 juhpetersen at gmail.com Sun Aug 21 07:14:16 2022 From: juhpetersen at gmail.com (Jens Petersen) Date: Sun, 21 Aug 2022 15:14:16 +0800 Subject: [Haskell-cafe] [ANNOUNCE] GHC 9.4.1 is now available In-Reply-To: <87v8r3wxo8.fsf@smart-cactus.org> References: <87v8r3wxo8.fsf@smart-cactus.org> Message-ID: On Mon, 8 Aug 2022 at 05:30, Ben Gamari wrote: > The GHC developers are very pleased to announce the availability of GHC > 9.4.1. > Thank you for the new major version release. I have built it for all current Fedora releases and EPEL9 in the ghc9.4 package. For those interested you can check and review the packaging here: https://src.fedoraproject.org/rpms/ghc9.4/tree/rawhide Jens -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivanperezdominguez at gmail.com Sun Aug 21 21:47:10 2022 From: ivanperezdominguez at gmail.com (Ivan Perez) Date: Sun, 21 Aug 2022 14:47:10 -0700 Subject: [Haskell-cafe] [ANN]: dunai-0.9.0, dunai-test-0.9.0, bearriver-0.13.6 Message-ID: Hi everyone! I've just released version 0.9.0 of the dunai libraries, which comes with version 0.13.6 of bearriver. For those unfamiliar, dunai is a reactive programming library structured around a notion of Monadic Stream Functions . dunai can be used to implement other reactive and FRP frameworks on top, including Classic FRP and Arrowized FRP variants. bearriver itself is an API-compatible implementation of Yampa. dunai also comes with a QuickCheck-based temporal testing library, and can be connected with the testing system haskell-titan. All versions of GHC from 7.6 to 9.4 are supported. *Release information* This is mainly a maintenance release. Among other changes, this version improves the documentation in dunai-test. Additionally, a function that was exposed unnecessarily is being deprecated in preparation for its future removal. - Release: https://github.com/ivanperez-keera/dunai/releases/tag/v0.9.0. - Hackage: - dunai: https://hackage.haskell.org/package/dunai. - dunai-test: https://hackage.haskell.org/package/dunai-test - bearriver: https://hackage.haskell.org/package/bearriver - Repo: https://github.com/ivanperez-keera/dunai. *Upcoming changes* We are synchronizing releases with the Yampa project to ensure that bearriver incorporates any changes added to Yampa. Additionally, the goal is to eventually use Yampa's tests also to give bearriver full test coverage. Two changes are being discussed that will potentially affect users: - The introduction of a new constraint in VectorSpace in simple-affine-space would alter the type constraints of some functions. See #298 . - A re-structuring of the API to better reflect the purpose of the implementation. This could also lead to a division of dunai into multiple libraries. See #305 . The next release is expected to be published on October 21, 2022. Happy Haskelling! Ivan -------------- next part -------------- An HTML attachment was scrubbed... URL: From rudy at matela.com.br Mon Aug 22 10:26:08 2022 From: rudy at matela.com.br (Rudy Matela) Date: Mon, 22 Aug 2022 12:26:08 +0200 Subject: [Haskell-cafe] =?utf-8?b?QU5OOiBMZWFuQ2hlY2sgdjEuMC4wIOKAkyBFbnVt?= =?utf-8?q?erative_Property_Testing?= Message-ID: Hello Haskell Café, A new version of LeanCheck is out (v1.0.0 ). LeanCheck is a property testing library (like QuickCheck) that tests values enumeratively. *Example.* Here is a simple example of LeanCheck in action showing that sorting is idempotent and list union is not commutative: > import Test.LeanCheck > import Data.List (sort, union) > check $ \xs -> sort (sort xs) == sort (xs::[Int]) +++ OK, passed 200 tests. > check $ \xs ys -> xs `union` ys == ys `union` (xs::[Int]) *** Failed! Falsifiable (after 4 tests): [] [0,0] LeanCheck works on all types that are instances of the Listable typeclass and is able to derive instances automatically using either Template Haskell or GHC.Generics. See LeanCheck’s Haddock documentation for more details. LeanCheck is compatible with Hspec , Tasty and test-framework . *What's new?* Version 1.0.0 signalizes stability in the API. LeanCheck has not actually changed much in the past couple of years and there are no significant differences between the early 0.9 series. *Installing.* You can find LeanCheck on Hackage or GitHub . It is also tracked on Stackage . You can install it with: $ cabal install leancheck – Rudy -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at well-typed.com Mon Aug 22 18:55:05 2022 From: ben at well-typed.com (Ben Gamari) Date: Mon, 22 Aug 2022 14:55:05 -0400 Subject: [Haskell-cafe] [ANNOUNCE] GHC 9.4.2 is now available Message-ID: <87lergun0v.fsf@smart-cactus.org> The GHC developers are happy to announce the availability of GHC 9.4.2. Binary distributions, source distributions, and documentation are available at downloads.haskell.org: https://downloads.haskell.org/ghc/9.4.2 This release is primarily a bugfix release addressing a few packaging issues found in 9.4.1. See the [release notes] for a full accounting. Note that, as GHC 9.4 is the first release series where the release artifacts are all generated by our new Hadrian build system, it is possible that there will be packaging issues. If you enounter trouble while using a binary distribution, please open a [ticket]. Likewise, if you are a downstream packager, do consider migrating to [Hadrian] to run your build; the Hadrian build system can be built using `cabal-install`, `stack`, or the in-tree [bootstrap script]. See the accompanying [blog post] for details on migrating packaging to Hadrian. We would also like to emphasize that GHC 9.4 must be used in conjunction with Cabal-3.8 or later. This is particularly important for Windows users due to changes in GHC's Windows toolchain. 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. Happy Haskelling, - Ben [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new [bootstrap script]: https://gitlab.haskell.org/ghc/ghc/-/blob/e2520df3fffa0cf22fb19c5fb872832d11c07d35/hadrian/bootstrap/README.md [Hadrian]: https://gitlab.haskell.org/ghc/ghc/-/blob/e2520df3fffa0cf22fb19c5fb872832d11c07d35/hadrian [release notes]: https://downloads.haskell.org/~ghc/9.4.2/docs/users_guide/9.4.2-notes.html [blog post]: https://www.haskell.org/ghc/blog/20220805-make-to-hadrian.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From leah at vuxu.org Mon Aug 22 20:56:49 2022 From: leah at vuxu.org (Leah Neukirchen) Date: Mon, 22 Aug 2022 22:56:49 +0200 Subject: [Haskell-cafe] Munich Haskell Meeting, 2022-08-25 @ 19:30 Message-ID: <87ilmk2e0e.fsf@vuxu.org> Dear all, This week, our monthly Munich Haskell Meeting will take place again on Wednesday, August 25 at *Hofbräukeller am Wiener Platz* at 19h30. For details see here: http://muenchen.haskell.bayern/dates.html If you plan to join, please add yourself to this dudle so we can look out for you: https://nuudel.digitalcourage.de/haskell-munich-aug-2022 (dudle is broken today, so we use nuudel instead.) Everybody is welcome! cu, -- Leah Neukirchen https://leahneukirchen.org/ From robstewart57 at gmail.com Tue Aug 23 07:01:40 2022 From: robstewart57 at gmail.com (Rob Stewart) Date: Tue, 23 Aug 2022 08:01:40 +0100 Subject: [Haskell-cafe] [ANN] gitlab-haskell 1.0.0.1 Message-ID: Hi, I'm pleased to announce the release of gitlab-haskell-1.0.0.1 . This library lifts the GitLab web API into Haskell. The library also has an event driven API for implementing server-side GitLab file hooks. This 1.0.0.1 release features: 1. Complete coverage of the GitLab v4 REST API. 2. An extensive suite of unit tests for parsing and serialising GitLab JSON objects. Documentation: https://hackage.haskell.org/package/gitlab-haskell Repository: https://gitlab.com/robstewart57/gitlab-haskell Details of the real-time API for GitLab events: https://www.macs.hw.ac.uk/~rs46/posts/2020-06-06-gitlab-system-hooks.html -- Rob Stewart https://www.macs.hw.ac.uk/~rs46/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From ikke at nicolast.be Sun Aug 28 13:37:48 2022 From: ikke at nicolast.be (Nicolas Trangez) Date: Sun, 28 Aug 2022 15:37:48 +0200 Subject: [Haskell-cafe] With cabal.project, what's the story about warning and -Werror compiler flags? Message-ID: <5508918b22c3a65b33cde607704d5e3c89be6c0f.camel@nicolast.be> All, Working on some project, I was wondering about best-practices and community standards for compiler flags now that `cabal.project` is a thing. Before, I put compiler warning flags like `-Wall` in `Ghc-Options` and `Cc-Options` in `mypackage.cabal` files. The use of `-Werror`, whilst (IMHO) useful in development and CI was a bit more troublesome, since having those in `package.cabal` (not under a default-disabled flag) was frowned upon (and even not allowed by Hackage?) Having these options in `mypackage.cabal` always felt slightly weird, since they are in no way required for a package to function: they're developer options, not user/consumer options. Where `-wavx2` could be a required `Cc-Options` setting for a package to build/function, `-Wall` is not. With the advent of `cabal.project`, it seems to me this is the ideal place to put developer flags: from what I understood, `cabal.project` doesn't influence sdist/Hackage distribution, and hence could contain all kind of GHC and C compiler flags that are useful during development but not required for a package to build/function, including `-Werror` (if desired by the project authors). Does this sound like a reasonable stance? If it is, I did run into a couple of issues getting things to actually work. Whilst putting `Ghc-Options` in a `Package mypackage` section in `cabal.project` seems to work, I'm unable to achieve the same resulsts for C compiler invocations. Presumably there's a `Gcc-Options` setting one can use (which is also generated in `cabal.project.local` by `cabal configure --gcc-options ...`). However, in testing, it appears said compiler optons are only passed to GCC when compiling, e.g., a HSC2HS file, but not when compiling a C file part of a `C-Sources` setting (whilst `Cc-Options` in `mypackage.cabal` are). Is there some discrepancy between what can be done from `cabal.project` vs. `mypackage.cabal`? Is this intentional? Am I trying to accomplish something that isn't/shouldn't be supported by Cabal in the first place? Cheers, Nicolas From nadine.and.henry at pobox.com Sun Aug 28 16:36:56 2022 From: nadine.and.henry at pobox.com (Henry Laxen) Date: Sun, 28 Aug 2022 09:36:56 -0700 Subject: [Haskell-cafe] Two mysteries Message-ID: <87sflg5npz.fsf@pobox.com> -- run this with ghci -package microlens-platform -package stm -package containers SC.hs {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE AllowAmbiguousTypes #-} {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE TemplateHaskell #-} module Games.SC where import qualified Data.Map.Strict as M import GHC.IO.Unsafe ( unsafePerformIO ) import Lens.Micro.Platform import Control.Concurrent.STM.TVar import Control.Concurrent.STM import Control.Monad.IO.Class type Lenstype f a b = (b -> f b) -> a -> f a instance Show a => Show (TVar a) where show x = unsafePerformIO $ do sx <- readTVarIO x return ("TVar: " <> show sx) newtype TMap k v = TMap (TVar (M.Map k (TVar v))) deriving Show -- TMap (TVar (Map k (TVar v))) -- ^^^^ modify this TVar to add/delete a key -- TMap (TVar (Map k (TVar v))) -- ^^^^ modify this TVar to change a value withKey :: (MonadIO m, Ord k) => k -> (Maybe v -> v) -> TMap k v -> m () withKey k f (TMap x) = liftIO $ do atomically $ do tMap <- readTVar x let mbK = M.lookup k tMap case mbK of -- insert a new (key,value) into the map Nothing -> do v' <- newTVar (f Nothing) let newMap = M.insert k v' tMap writeTVar x newMap Just tv -> do -- modify the value of an existing key v' <- readTVar tv let newV = f (Just v') writeTVar tv newV return () class State a where type StateKey a :: * type StateValue a :: * lensTmap :: Functor f => Lenstype f a (TMap (StateKey a) (StateValue a)) lensKey :: Functor f => Lenstype f a (StateKey a) lensCounter :: Functor f => Lenstype f (StateValue a) Int updateState state f = liftIO $ do let key = state ^. lensKey -- read the key mutable = state ^. lensTmap -- find the TVar of the TMap withKey key (\(Just x) -> x & lensCounter %~ f) mutable -- update it -- THE FIRST MYSTERY: If I use the inferred type explicitly for updateState -- above, this no longer compiles. I get a "could not deduce" error -- reproduced below: -- xupdateState -- :: (MonadIO m, Ord (StateKey s), State s, State a, -- StateValue s ~ StateValue a) => -- s -> (Int -> Int) -> m () -- xupdateState state f = liftIO $ do -- let -- key = state ^. lensKey -- read the key -- mutable = state ^. lensTmap -- find the TVar of the TMap -- withKey key (\(Just x) -> x & lensCounter %~ f) mutable -- update it -- /home/henry/nadineloveshenry/projects/nlh/src/Games/SC.hs:84:33-43: error: -- • Could not deduce: StateValue a0 ~ StateValue a -- from the context: (MonadIO m, Ord (StateKey s), State s, State a, -- StateValue s ~ StateValue a) -- bound by the type signature for: -- xupdateState :: forall (m :: * -> *) s a. -- (MonadIO m, Ord (StateKey s), State s, State a, -- StateValue s ~ StateValue a) => -- s -> (Int -> Int) -> m () -- at /home/henry/nadineloveshenry/projects/nlh/src/Games/SC.hs:(76,1)-(79,30) -- Expected type: ASetter (StateValue a) (StateValue a) Int Int -- Actual type: Lenstype -- Data.Functor.Identity.Identity (StateValue a0) Int -- NB: ‘StateValue’ is a non-injective type family -- The type variable ‘a0’ is ambiguous -- • In the first argument of ‘(%~)’, namely ‘lensCounter’ -- In the second argument of ‘(&)’, namely ‘lensCounter %~ f’ -- In the expression: x & lensCounter %~ f -- • Relevant bindings include -- x :: StateValue a -- (bound at /home/henry/nadineloveshenry/projects/nlh/src/Games/SC.hs:84:23) -- mutable :: TMap (StateKey s) (StateValue a) -- (bound at /home/henry/nadineloveshenry/projects/nlh/src/Games/SC.hs:83:5) data SampleState = SampleState { _key :: String , _tMap :: TMap String SampleValue } deriving Show data SampleValue = SampleValue { _counter :: Int , _other :: () } deriving Show $(makeLenses ''SampleState) $(makeLenses ''SampleValue) makeSampleState :: IO SampleState makeSampleState = do let sampleValue = SampleValue 1 () tvar1 <- newTVarIO sampleValue let sampleTMap = M.fromList [("a", tvar1)] tvar2 <- newTVarIO sampleTMap return (SampleState "a" (TMap tvar2)) -- I can show the result of makeSampleState: -- λ> makeSampleState -- SampleState {_key = "a", _tMap = TMap TVar: fromList [("a",TVar: SampleValue {_counter = 1, _other = ()})]} bump1 :: IO () bump1 = do xss <- makeSampleState let xTmap = xss ^. tMap withKey "a" (\(Just x) -> x & counter %~ (+1)) xTmap print xTmap -- Everything here is tickety-boo -- λ> bump1 -- TMap TVar: fromList [("a",TVar: SampleValue {_counter = 2, _other = ()})] -- Now let's make SampleState an instance of State instance State SampleState where type StateKey SampleState = String type StateValue SampleState = SampleValue lensTmap = tMap lensKey = key lensCounter = counter -- THE SECOND MYSTERY: now lets try bump1 with the type family, but there is no joy -- bump2 :: IO () -- bump2 = do -- xss <- makeSampleState -- let xTmap = xss ^. lensTmap -- withKey "a" (\(Just x) -> x & lensCounter %~ (+1)) xTmap -- print xTmap -- SC.hs:163:33-43: error: -- • Couldn't match type ‘StateValue a0’ with ‘SampleValue’ -- Expected type: ASetter SampleValue SampleValue Int Int -- Actual type: Lenstype -- Data.Functor.Identity.Identity (StateValue a0) Int -- The type variable ‘a0’ is ambiguous -- • In the first argument of ‘(%~)’, namely ‘lensCounter’ -- In the second argument of ‘(&)’, namely ‘lensCounter %~ (+ 1)’ -- In the expression: x & lensCounter %~ (+ 1) -- Can someone please explain what is going on, or point me at a book/paper -- Thanks in advance. -- You can load this into ghci and uncomment to "bad" code to see for -- yourself what happens -- Nadine and Henry Laxen The rest is silence Gral. Manuel Márquez de León 1301 Onix #2302 Zona Urban Rio Never try to teach a pig to sing; Tijuana It wastes your time +52 (333) 667-8633 And it annoys the pig From tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk Sun Aug 28 17:23:45 2022 From: tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk (Tom Ellis) Date: Sun, 28 Aug 2022 18:23:45 +0100 Subject: [Haskell-cafe] Two mysteries In-Reply-To: <87sflg5npz.fsf@pobox.com> References: <87sflg5npz.fsf@pobox.com> Message-ID: On Sun, Aug 28, 2022 at 09:36:56AM -0700, Henry Laxen wrote: > class State a where > type StateKey a :: * > type StateValue a :: * > lensTmap :: Functor f => Lenstype f a (TMap (StateKey a) (StateValue a)) > lensKey :: Functor f => Lenstype f a (StateKey a) > lensCounter :: Functor f => Lenstype f (StateValue a) Int > > bump1 :: IO () > bump1 = do > xss <- makeSampleState > let xTmap = xss ^. tMap > withKey "a" (\(Just x) -> x & counter %~ (+1)) xTmap > print xTmap > > -- Everything here is tickety-boo > -- λ> bump1 > -- TMap TVar: fromList [("a",TVar: SampleValue {_counter = 2, _other = ()})] > > -- THE SECOND MYSTERY: now lets try bump1 with the type family, but there is no joy > > -- bump2 :: IO () > -- bump2 = do > -- xss <- makeSampleState > -- let xTmap = xss ^. lensTmap > -- withKey "a" (\(Just x) -> x & lensCounter %~ (+1)) xTmap > -- print xTmap This one is fairly easy to explain: `lensCounter` is a function that can work for each `a` that is an instance of `State`. So, the `lensCounter` for which `a` should it be using here? You think `a` should be `SampleState` because you've defined the following instance, and you are trying to use `lensCounter` on a value of type `SampleValue`. > instance State SampleState where > type StateKey SampleState = String > type StateValue SampleState = SampleValue > lensTmap = tMap > lensKey = key > lensCounter = counter But, suppose someone had also defined the following instance > instance State () where > type StateKey () = String > type StateValue () = SampleValue > lensTmap = anotherTMap > lensKey = anotherKey > lensCounter = anotherCounter When it comes to determine what `lensCounter` to use, `anotherCounter` would work equally well as `counter`, as would the `lensCounter` of _any_ `State` instance `a` for which `StateValue a = SampleValue`. There's no unique choice to be made here, so type checking can't proceed. There are various ways to get around this, for example making `State` a multiparameter type class and adding functional depencies. Perhaps the following will work: > class State a k v | a -> k, a -> v where > lensTmap :: Functor f => Lenstype f a (TMap k v) > lensKey :: Functor f => Lenstype f a k > lensCounter :: Functor f => Lenstype f v Int > > instance State SampleState String SampleValue where > lensTmap = tMap > lensKey = key > lensCounter = counter Tom From jclites at mac.com Sun Aug 28 17:25:49 2022 From: jclites at mac.com (Jeff Clites) Date: Sun, 28 Aug 2022 10:25:49 -0700 Subject: [Haskell-cafe] Two mysteries In-Reply-To: <87sflg5npz.fsf@pobox.com> References: <87sflg5npz.fsf@pobox.com> Message-ID: <9C85CAB6-851E-4D3F-B91F-616595A0E7C7@mac.com> I'm probably just missing something, but in this: > -- xupdateState > -- :: (MonadIO m, Ord (StateKey s), State s, State a, > -- StateValue s ~ StateValue a) => > -- s -> (Int -> Int) -> m () ... > -- • Could not deduce: StateValue a0 ~ StateValue a ... > -- The type variable ‘a0’ is ambiguous `a` is mentioned in the constraint but isn't used in the signature. Is that the problem? Jeff > On Aug 28, 2022, at 9:36 AM, Henry Laxen wrote: > > > > -- run this with ghci -package microlens-platform -package stm -package containers SC.hs > > {-# LANGUAGE TypeFamilies #-} > {-# LANGUAGE AllowAmbiguousTypes #-} > {-# LANGUAGE FlexibleContexts #-} > {-# LANGUAGE TemplateHaskell #-} > > module Games.SC where > > import qualified Data.Map.Strict as M > import GHC.IO.Unsafe ( unsafePerformIO ) > import Lens.Micro.Platform > import Control.Concurrent.STM.TVar > import Control.Concurrent.STM > import Control.Monad.IO.Class > > type Lenstype f a b = (b -> f b) -> a -> f a > instance Show a => Show (TVar a) where > show x = unsafePerformIO $ do > sx <- readTVarIO x > return ("TVar: " <> show sx) > > newtype TMap k v = TMap (TVar (M.Map k (TVar v))) deriving Show > > -- TMap (TVar (Map k (TVar v))) > -- ^^^^ modify this TVar to add/delete a key > -- TMap (TVar (Map k (TVar v))) > -- ^^^^ modify this TVar to change a value > > withKey :: (MonadIO m, Ord k) => k -> (Maybe v -> v) -> TMap k v -> m () > withKey k f (TMap x) = liftIO $ do > atomically $ do > tMap <- readTVar x > let > mbK = M.lookup k tMap > case mbK of -- insert a new (key,value) into the map > Nothing -> do > v' <- newTVar (f Nothing) > let > newMap = M.insert k v' tMap > writeTVar x newMap > Just tv -> do -- modify the value of an existing key > v' <- readTVar tv > let newV = f (Just v') > writeTVar tv newV > return () > > class State a where > type StateKey a :: * > type StateValue a :: * > lensTmap :: Functor f => Lenstype f a (TMap (StateKey a) (StateValue a)) > lensKey :: Functor f => Lenstype f a (StateKey a) > lensCounter :: Functor f => Lenstype f (StateValue a) Int > > updateState state f = liftIO $ do > let > key = state ^. lensKey -- read the key > mutable = state ^. lensTmap -- find the TVar of the TMap > withKey key (\(Just x) -> x & lensCounter %~ f) mutable -- update it > > -- THE FIRST MYSTERY: If I use the inferred type explicitly for updateState > -- above, this no longer compiles. I get a "could not deduce" error > -- reproduced below: > > -- xupdateState > -- :: (MonadIO m, Ord (StateKey s), State s, State a, > -- StateValue s ~ StateValue a) => > -- s -> (Int -> Int) -> m () > -- xupdateState state f = liftIO $ do > -- let > -- key = state ^. lensKey -- read the key > -- mutable = state ^. lensTmap -- find the TVar of the TMap > -- withKey key (\(Just x) -> x & lensCounter %~ f) mutable -- update it > > -- /home/henry/nadineloveshenry/projects/nlh/src/Games/SC.hs:84:33-43: error: > -- • Could not deduce: StateValue a0 ~ StateValue a > -- from the context: (MonadIO m, Ord (StateKey s), State s, State a, > -- StateValue s ~ StateValue a) > -- bound by the type signature for: > -- xupdateState :: forall (m :: * -> *) s a. > -- (MonadIO m, Ord (StateKey s), State s, State a, > -- StateValue s ~ StateValue a) => > -- s -> (Int -> Int) -> m () > -- at /home/henry/nadineloveshenry/projects/nlh/src/Games/SC.hs:(76,1)-(79,30) > -- Expected type: ASetter (StateValue a) (StateValue a) Int Int > -- Actual type: Lenstype > -- Data.Functor.Identity.Identity (StateValue a0) Int > -- NB: ‘StateValue’ is a non-injective type family > -- The type variable ‘a0’ is ambiguous > -- • In the first argument of ‘(%~)’, namely ‘lensCounter’ > -- In the second argument of ‘(&)’, namely ‘lensCounter %~ f’ > -- In the expression: x & lensCounter %~ f > -- • Relevant bindings include > -- x :: StateValue a > -- (bound at /home/henry/nadineloveshenry/projects/nlh/src/Games/SC.hs:84:23) > -- mutable :: TMap (StateKey s) (StateValue a) > -- (bound at /home/henry/nadineloveshenry/projects/nlh/src/Games/SC.hs:83:5) > > > data SampleState = SampleState > { > _key :: String > , _tMap :: TMap String SampleValue > } deriving Show > > data SampleValue = SampleValue > { > _counter :: Int > , _other :: () > } deriving Show > > $(makeLenses ''SampleState) > $(makeLenses ''SampleValue) > > makeSampleState :: IO SampleState > makeSampleState = do > let sampleValue = SampleValue 1 () > tvar1 <- newTVarIO sampleValue > let sampleTMap = M.fromList [("a", tvar1)] > tvar2 <- newTVarIO sampleTMap > return (SampleState "a" (TMap tvar2)) > > -- I can show the result of makeSampleState: > -- λ> makeSampleState > -- SampleState {_key = "a", _tMap = TMap TVar: fromList [("a",TVar: SampleValue {_counter = 1, _other = ()})]} > > bump1 :: IO () > bump1 = do > xss <- makeSampleState > let xTmap = xss ^. tMap > withKey "a" (\(Just x) -> x & counter %~ (+1)) xTmap > print xTmap > > -- Everything here is tickety-boo > -- λ> bump1 > -- TMap TVar: fromList [("a",TVar: SampleValue {_counter = 2, _other = ()})] > > -- Now let's make SampleState an instance of State > > instance State SampleState where > type StateKey SampleState = String > type StateValue SampleState = SampleValue > lensTmap = tMap > lensKey = key > lensCounter = counter > > -- THE SECOND MYSTERY: now lets try bump1 with the type family, but there is no joy > > -- bump2 :: IO () > -- bump2 = do > -- xss <- makeSampleState > -- let xTmap = xss ^. lensTmap > -- withKey "a" (\(Just x) -> x & lensCounter %~ (+1)) xTmap > -- print xTmap > > -- SC.hs:163:33-43: error: > -- • Couldn't match type ‘StateValue a0’ with ‘SampleValue’ > -- Expected type: ASetter SampleValue SampleValue Int Int > -- Actual type: Lenstype > -- Data.Functor.Identity.Identity (StateValue a0) Int > -- The type variable ‘a0’ is ambiguous > -- • In the first argument of ‘(%~)’, namely ‘lensCounter’ > -- In the second argument of ‘(&)’, namely ‘lensCounter %~ (+ 1)’ > -- In the expression: x & lensCounter %~ (+ 1) > > -- Can someone please explain what is going on, or point me at a book/paper > -- Thanks in advance. > > -- You can load this into ghci and uncomment to "bad" code to see for > -- yourself what happens > > > > -- > Nadine and Henry Laxen The rest is silence > Gral. Manuel Márquez de León 1301 > Onix #2302 > Zona Urban Rio Never try to teach a pig to sing; > Tijuana It wastes your time > +52 (333) 667-8633 And it annoys the pig > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. From tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk Sun Aug 28 17:31:18 2022 From: tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk (Tom Ellis) Date: Sun, 28 Aug 2022 18:31:18 +0100 Subject: [Haskell-cafe] Two mysteries In-Reply-To: <87sflg5npz.fsf@pobox.com> References: <87sflg5npz.fsf@pobox.com> Message-ID: On Sun, Aug 28, 2022 at 09:36:56AM -0700, Henry Laxen wrote: > class State a where > type StateKey a :: * > type StateValue a :: * > lensTmap :: Functor f => Lenstype f a (TMap (StateKey a) (StateValue a)) > lensKey :: Functor f => Lenstype f a (StateKey a) > lensCounter :: Functor f => Lenstype f (StateValue a) Int > > updateState state f = liftIO $ do > let > key = state ^. lensKey -- read the key > mutable = state ^. lensTmap -- find the TVar of the TMap > withKey key (\(Just x) -> x & lensCounter %~ f) mutable -- update it > > -- THE FIRST MYSTERY: If I use the inferred type explicitly for updateState > -- above, this no longer compiles. I get a "could not deduce" error > -- reproduced below: > > -- xupdateState > -- :: (MonadIO m, Ord (StateKey s), State s, State a, > -- StateValue s ~ StateValue a) => > -- s -> (Int -> Int) -> m () > -- xupdateState state f = liftIO $ do > -- let > -- key = state ^. lensKey -- read the key > -- mutable = state ^. lensTmap -- find the TVar of the TMap > -- withKey key (\(Just x) -> x & lensCounter %~ f) mutable -- update it AllowAmbiguousTypes is what's allowing you to get tangled into this knot. I suggest you don't enable that extension unless you feel confident you are equipped for axe warfare. The behaviour here is as though the type checker has turned `lensCounter` in the body into `lensCounter @a` for a fresh type variable `a`, and then applied the necessary constraints to the context. Normally the type checker would notice that `a` is ambiguous and refuse to continue. AllowAmbiguousTypes defers that check to the use site. That means I don't think it makes any difference to you, because even though `updateState` with inferred type signature will compile I bet you can't use it. Give it a try! I guess you'll get an "ambiguous type" error at the use site. Tom From dreixel at gmail.com Sun Aug 28 19:04:50 2022 From: dreixel at gmail.com (=?UTF-8?Q?Jos=C3=A9_Pedro_Magalh=C3=A3es?=) Date: Sun, 28 Aug 2022 20:04:50 +0100 Subject: [Haskell-cafe] Three Haskell roles with Core Strats at Standard Chartered Message-ID: Core Strats at Standard Chartered Bank are hiring Haskell developers again. We're currently looking for three developers, and we're flexible with regards to seniority / experience. The head of our group has given a talk at the Haskell Implementer’s Workshop last year where he described the team and what we do: https://www.youtube.com/watch?v=A70SN7vFsKU These roles are specifically for Applications & Services development, so expect some GUI work and plenty of stakeholder interaction. Applications should go via these links: Warsaw: https://scb.taleo.net/careersection/ex/jobdetail.ftl?job=2200023433 for direct employment, or CoreStratsRoles at sc.com for contracting London: https://scb.taleo.net/careersection/ex/jobdetail.ftl?job=2200023448 Singapore: https://scb.taleo.net/careersection/ex/jobdetail.ftl?job=2200017272 Shanghai: reach out to CoreStratsRoles at sc.com The Warsaw position is open to both contractors and direct employment, whereas the others are only open for direct employment. Standard Chartered supports (practically fully) remote working, but only from the country of payroll, and after an initial 3-month in-office period. We cover visa and relocation costs for successful employment applicants. Note that the first step of the application is a Valued Behaviours Assessment and it is quite important: our team won’t be able to see your application until you pass this assessment. Feel free to contact us at CoreStratsRoles at sc.com if you have any questions about these positions. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mikolaj at well-typed.com Sun Aug 28 19:19:30 2022 From: mikolaj at well-typed.com (Mikolaj Konarski) Date: Sun, 28 Aug 2022 21:19:30 +0200 Subject: [Haskell-cafe] With cabal.project, what's the story about warning and -Werror compiler flags? In-Reply-To: <5508918b22c3a65b33cde607704d5e3c89be6c0f.camel@nicolast.be> References: <5508918b22c3a65b33cde607704d5e3c89be6c0f.camel@nicolast.be> Message-ID: Let me CC to cabal-devel at haskell.org. On Sun, Aug 28, 2022 at 3:39 PM Nicolas Trangez wrote: > > All, > > Working on some project, I was wondering about best-practices and > community standards for compiler flags now that `cabal.project` is a > thing. > > Before, I put compiler warning flags like `-Wall` in `Ghc-Options` and > `Cc-Options` in `mypackage.cabal` files. The use of `-Werror`, whilst > (IMHO) useful in development and CI was a bit more troublesome, since > having those in `package.cabal` (not under a default-disabled flag) was > frowned upon (and even not allowed by Hackage?) > > Having these options in `mypackage.cabal` always felt slightly weird, > since they are in no way required for a package to function: they're > developer options, not user/consumer options. Where `-wavx2` could be a > required `Cc-Options` setting for a package to build/function, `-Wall` > is not. > > With the advent of `cabal.project`, it seems to me this is the ideal > place to put developer flags: from what I understood, `cabal.project` > doesn't influence sdist/Hackage distribution, and hence could contain > all kind of GHC and C compiler flags that are useful during development > but not required for a package to build/function, including `-Werror` > (if desired by the project authors). > > Does this sound like a reasonable stance? > > If it is, I did run into a couple of issues getting things to actually > work. Whilst putting `Ghc-Options` in a `Package mypackage` section in > `cabal.project` seems to work, I'm unable to achieve the same resulsts > for C compiler invocations. Presumably there's a `Gcc-Options` setting > one can use (which is also generated in `cabal.project.local` by `cabal > configure --gcc-options ...`). However, in testing, it appears said > compiler optons are only passed to GCC when compiling, e.g., a HSC2HS > file, but not when compiling a C file part of a `C-Sources` setting > (whilst `Cc-Options` in `mypackage.cabal` are). > > Is there some discrepancy between what can be done from `cabal.project` > vs. `mypackage.cabal`? Is this intentional? Am I trying to accomplish > something that isn't/shouldn't be supported by Cabal in the first > place? > > Cheers, > > Nicolas > _______________________________________________ > 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 mikolaj at well-typed.com Mon Aug 29 04:58:07 2022 From: mikolaj at well-typed.com (Mikolaj Konarski) Date: Mon, 29 Aug 2022 06:58:07 +0200 Subject: [Haskell-cafe] With cabal.project, what's the story about warning and -Werror compiler flags? In-Reply-To: References: <5508918b22c3a65b33cde607704d5e3c89be6c0f.camel@nicolast.be> Message-ID: Hi Nicolas, > Before, I put compiler warning flags like `-Wall` in `Ghc-Options` > .. > Having these options in `mypackage.cabal` always felt slightly weird, > since they are in no way required for a package to function: they're > developer options, not user/consumer options. They'd be certainly out of place in a binary package. However, a source package is meant to be compiled, so instructing the compiler to produce warnings during compilation seems relevant. A related reason is that IIRC haskell-ci does `cabal sdist` and then runs all its operations based on the resulting source package. So, if you want to see warnings in CI logs, you need to retain the relevant instruction in the source package created by `cabal sdist`. And warnings sometimes help to explain why compilation fails or why the resulting binary misbehaves. > > If it is, I did run into a couple of issues getting things to actually > > work. Whilst putting `Ghc-Options` in a `Package mypackage` section in > > `cabal.project` seems to work, I'm unable to achieve the same resulsts > > for C compiler invocations. Presumably there's a `Gcc-Options` setting > > one can use (which is also generated in `cabal.project.local` by `cabal > > configure --gcc-options ...`). However, in testing, it appears said > > compiler optons are only passed to GCC when compiling, e.g., a HSC2HS > > file, but not when compiling a C file part of a `C-Sources` setting > > (whilst `Cc-Options` in `mypackage.cabal` are). > > > > Is there some discrepancy between what can be done from `cabal.project` > > vs. `mypackage.cabal`? Is this intentional? Am I trying to accomplish > > something that isn't/shouldn't be supported by Cabal in the first > > place? That sounds like a bug. Is there anything relevant in the issue tracker? All the best, Mikolaj From mikolaj at well-typed.com Mon Aug 29 09:53:38 2022 From: mikolaj at well-typed.com (Mikolaj Konarski) Date: Mon, 29 Aug 2022 11:53:38 +0200 Subject: [Haskell-cafe] With cabal.project, what's the story about warning and -Werror compiler flags? In-Reply-To: References: <5508918b22c3a65b33cde607704d5e3c89be6c0f.camel@nicolast.be> Message-ID: Another angle is that cabal.project is for a set of packages and foo.cabal is for an individual package foo. That distinction would suggest cabal.project is only for compiler options that affect all packages in the project. However, with 1-package projects, this is a moot point. OTOH, given that Hackage does not accept package collections, but only individual packages, and this is how packages are compiled as dependencies, all packages (or at least all libraries) need to be ready to behave like 1-package projects even bereft of cabal.project files. (BTW, I wonder, perhaps Hackage should accept package collection for non-libraries, that is, for packages that are not intended solely to be dependencies of other packages.) Perhaps putting in cabal.project only what is not needed for the use as a dependency of another package makes sense. E.g., only the options affecting executable components of the packages. On Mon, Aug 29, 2022 at 6:58 AM Mikolaj Konarski wrote: > > Hi Nicolas, > > > Before, I put compiler warning flags like `-Wall` in `Ghc-Options` > > .. > > Having these options in `mypackage.cabal` always felt slightly weird, > > since they are in no way required for a package to function: they're > > developer options, not user/consumer options. > > They'd be certainly out of place in a binary package. However, > a source package is meant to be compiled, so instructing > the compiler to produce warnings during compilation seems relevant. > A related reason is that IIRC haskell-ci does `cabal sdist` and then > runs all its operations based on the resulting source package. > So, if you want to see warnings in CI logs, you need to retain > the relevant instruction in the source package created by `cabal sdist`. > And warnings sometimes help to explain why compilation fails > or why the resulting binary misbehaves. > > > > If it is, I did run into a couple of issues getting things to actually > > > work. Whilst putting `Ghc-Options` in a `Package mypackage` section in > > > `cabal.project` seems to work, I'm unable to achieve the same resulsts > > > for C compiler invocations. Presumably there's a `Gcc-Options` setting > > > one can use (which is also generated in `cabal.project.local` by `cabal > > > configure --gcc-options ...`). However, in testing, it appears said > > > compiler optons are only passed to GCC when compiling, e.g., a HSC2HS > > > file, but not when compiling a C file part of a `C-Sources` setting > > > (whilst `Cc-Options` in `mypackage.cabal` are). > > > > > > Is there some discrepancy between what can be done from `cabal.project` > > > vs. `mypackage.cabal`? Is this intentional? Am I trying to accomplish > > > something that isn't/shouldn't be supported by Cabal in the first > > > place? > > That sounds like a bug. Is there anything relevant in the issue tracker? > > All the best, > Mikolaj From emilypi at cohomolo.gy Tue Aug 30 01:20:11 2022 From: emilypi at cohomolo.gy (Emily Pillmore) Date: Tue, 30 Aug 2022 01:20:11 +0000 Subject: [Haskell-cafe] [ANN] mtl-2.3.1-rc1 Message-ID: Hi Everyone, mtl-2.3.1-rc1 ( https://github.com/haskell/mtl/releases/tag/v2.3.1-rc1 ) is up on Github. We'll give this a 2 week window for issues relating to the changelog, and then do a release. Please review and upgrade if you're interested. Backported is also a migration doc for people interested in migrating to mtl-2.3. You can find it in the repo. Special thanks to Koz and everyone else who contributed. Cheers, E -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Tue Aug 30 06:30:34 2022 From: mail at joachim-breitner.de (Joachim Breitner) Date: Tue, 30 Aug 2022 08:30:34 +0200 Subject: [Haskell-cafe] GHC Proposals session at Haskell Symposium at ICFP Message-ID: <6c8dc251226301ec423fcca18650f5ce3e4b0954.camel@joachim-breitner.de> Dear friends of GHC, this year’s Haskell Symposium will host a special “GHC Proposals session” where current, future and past GHC Proposals can be presented and discussed: https://icfp22.sigplan.org/home/haskellsymp-2022#GHC-Proposals-Session I invite all GHC Proposal authors (or otherwise interested party) who are in Ljubljana to present your ideas and plans; just e-mail me if you want a slot. I also invite everyone else – users, developers, educators – to join the session for the discussions of these proposals. Your chance to get your voice heard, and not just your writing on GitHub! Cheers, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ From athas at sigkill.dk Tue Aug 30 11:44:37 2022 From: athas at sigkill.dk (Troels Henriksen) Date: Tue, 30 Aug 2022 13:44:37 +0200 Subject: [Haskell-cafe] Package takeover request for fgl Message-ID: <87y1v65522.fsf@sigkill.dk> I am requesting to take over the package fgl: https://hackage.haskell.org/package/fgl It is currently broken in GHC 9.4, which is fixed by this pull request: https://github.com/haskell/fgl/pull/104 The maintainer Ivan Miljenovic has not been active on GitHub since January. I wrote Ivan on August 12th offering to help out with maintenance, but have received no response yet. The package is part of the 'haskell' organisation on GitHub. I don't know whether that is supposed to signify some kind of "community maintenance" (it appears Ivan is not the original author of fgl), but I would eventually need Hackage upload rights as well. From ikke at nicolast.be Tue Aug 30 12:00:27 2022 From: ikke at nicolast.be (Nicolas Trangez) Date: Tue, 30 Aug 2022 14:00:27 +0200 Subject: [Haskell-cafe] With cabal.project, what's the story about warning and -Werror compiler flags? In-Reply-To: References: <5508918b22c3a65b33cde607704d5e3c89be6c0f.camel@nicolast.be> Message-ID: <27c0ed3a3128f592f7cfc117db23c860480b31de.camel@nicolast.be> Hey Mikolaj, On Mon, 2022-08-29 at 06:58 +0200, Mikolaj Konarski wrote: > Hi Nicolas, > > > Before, I put compiler warning flags like `-Wall` in `Ghc-Options` > > .. > > Having these options in `mypackage.cabal` always felt slightly > > weird, > > since they are in no way required for a package to function: > > they're > > developer options, not user/consumer options. > > They'd be certainly out of place in a binary package. However, > a source package is meant to be compiled, so instructing > the compiler to produce warnings during compilation seems relevant. I was under the impression (but could be mistaken) that Cabal doesn't show warnings while building dependencies. Even if it would, and some warning passes by, what's a user (of some package depending on mine) supposed to do when such warning(s) pass by, as long as it doesn't make compilation fail? > A related reason is that IIRC haskell-ci does `cabal sdist` and then > runs all its operations based on the resulting source package. Indeed it does. Hence, I configured HaskellCI to copy the warnings (and -Werror) from the project's cabal.project into the one it generates, for exactly this reason. As long as only warnings are used in ghc-options of cabal.project, there shouldn't be a difference between build'ability of the sdist, but we could make things fail in CI if warnings pop up (for the supported/tested GHC versions only, of course). > So, if you want to see warnings in CI logs, you need to retain > the relevant instruction in the source package created by `cabal > sdist`. I don't think it's OK to rely on "people looking at CI logs". If CI passes, then things are in good shape, no matter what's in the CI logs. Hence, the only way to ensure no code introducing warnings gets introduced, is by having -Werror in CI. > And warnings sometimes help to explain why compilation fails > or why the resulting binary misbehaves. Fair point, in some cases. > > > > If it is, I did run into a couple of issues getting things to > > > actually > > > work. Whilst putting `Ghc-Options` in a `Package mypackage` > > > section in > > > `cabal.project` seems to work, I'm unable to achieve the same > > > resulsts > > > for C compiler invocations. Presumably there's a `Gcc-Options` > > > setting > > > one can use (which is also generated in `cabal.project.local` by > > > `cabal > > > configure --gcc-options ...`). However, in testing, it appears > > > said > > > compiler optons are only passed to GCC when compiling, e.g., a > > > HSC2HS > > > file, but not when compiling a C file part of a `C-Sources` > > > setting > > > (whilst `Cc-Options` in `mypackage.cabal` are). > > > > > > Is there some discrepancy between what can be done from > > > `cabal.project` > > > vs. `mypackage.cabal`? Is this intentional? Am I trying to > > > accomplish > > > something that isn't/shouldn't be supported by Cabal in the first > > > place? > > That sounds like a bug. Is there anything relevant in the issue > tracker? Not that I could find. I should work on a minimal reproducible test- case and file something. Meanwhile, I guess from the feedback, what'd be best is to - Keep warnings in package.cabal ghc-options/cc-options etc - Add -Werror in cabal.project so things fail on dev machines - Configure HaskellCI to have -Werror as well, given a no-warnings policy Nicolas From mikolaj at well-typed.com Tue Aug 30 13:18:08 2022 From: mikolaj at well-typed.com (Mikolaj Konarski) Date: Tue, 30 Aug 2022 15:18:08 +0200 Subject: [Haskell-cafe] With cabal.project, what's the story about warning and -Werror compiler flags? In-Reply-To: <27c0ed3a3128f592f7cfc117db23c860480b31de.camel@nicolast.be> References: <5508918b22c3a65b33cde607704d5e3c89be6c0f.camel@nicolast.be> <27c0ed3a3128f592f7cfc117db23c860480b31de.camel@nicolast.be> Message-ID: > I was under the impression (but could be mistaken) that Cabal doesn't > show warnings while building dependencies. I don't remember, either, and it depends on commandline options, but I think it does show the full log at least when a dependency fails to compile. > Not that I could find. I should work on a minimal reproducible test- > case and file something. Yes, thank you, please do. > - Keep warnings in package.cabal ghc-options/cc-options etc > - Add -Werror in cabal.project so things fail on dev machines > - Configure HaskellCI to have -Werror as well, given a no-warnings > policy Brutal but effective. :) From olf at aatal-apotheke.de Tue Aug 30 13:30:39 2022 From: olf at aatal-apotheke.de (Olaf Klinke) Date: Tue, 30 Aug 2022 15:30:39 +0200 Subject: [Haskell-cafe] selectively allow alternatives in a sum type Message-ID: <9c38c719bc507fbde3109d026bc6ed639e86af63.camel@aatal-apotheke.de> Dear Café, Is there prior art/existing packages for the following? Is it maybefunctional programming folklore? Is it a sign of bad program design? Sometimes I feel the need to selectively allow or disallow alternatives in a sum type. That is, suppose we have a sum type data Foo = LeftFoo !A | RightFoo !B and at some places in the program we want the type system to enforce that only the constructor LeftFoo can be used. My solution would be to use a strict version of Data.Functor.Const and make the type higher rank: newtype Const' a b = Const' !a -- Const' Void b ~ Void -- Const' () b ~ () data Foo' f = LeftFoo' !A | RightFoo' !(f B) type Foo = Foo' Identity type LeftFoo = Foo' (Const' Void) -- can not construct a RightFoo' The advantage over defining LeftFoo as an entirely different type is that Foo and LeftFoo can share functions operating entirely on the left option. Olaf From olf at aatal-apotheke.de Tue Aug 30 13:57:27 2022 From: olf at aatal-apotheke.de (Olaf Klinke) Date: Tue, 30 Aug 2022 15:57:27 +0200 Subject: [Haskell-cafe] [Fwd: selectively allow alternatives in a sum type] References: <9c38c719bc507fbde3109d026bc6ed639e86af63.camel@aatal-apotheke.de> Message-ID: <98d7722432234bb1fee0c2b4fe03881994354ab2.camel@aatal-apotheke.de> Disregard Const' below, Data.Functor.Const as a newtype is always strict, as is Identity. That also ensures Foo' Identity is isomorphic to the original Foo. Apologies for the noise. Olaf -------- Forwarded Message -------- From: Olaf Klinke To: Haskell Café Subject: selectively allow alternatives in a sum type Date: Tue, 30 Aug 2022 15:30:39 +0200 Dear Café, Is there prior art/existing packages for the following? Is it maybefunctional programming folklore? Is it a sign of bad program design? Sometimes I feel the need to selectively allow or disallow alternatives in a sum type. That is, suppose we have a sum type data Foo = LeftFoo !A | RightFoo !B and at some places in the program we want the type system to enforce that only the constructor LeftFoo can be used. My solution would be to use a strict version of Data.Functor.Const and make the type higher rank: newtype Const' a b = Const' !a -- Const' Void b ~ Void -- Const' () b ~ () data Foo' f = LeftFoo' !A | RightFoo' !(f B) type Foo = Foo' Identity type LeftFoo = Foo' (Const' Void) -- can not construct a RightFoo' The advantage over defining LeftFoo as an entirely different type is that Foo and LeftFoo can share functions operating entirely on the left option. Olaf From oleg.grenrus at iki.fi Tue Aug 30 14:10:01 2022 From: oleg.grenrus at iki.fi (Oleg Grenrus) Date: Tue, 30 Aug 2022 17:10:01 +0300 Subject: [Haskell-cafe] selectively allow alternatives in a sum type In-Reply-To: <9c38c719bc507fbde3109d026bc6ed639e86af63.camel@aatal-apotheke.de> References: <9c38c719bc507fbde3109d026bc6ed639e86af63.camel@aatal-apotheke.de> Message-ID: <90b25fdf-050e-4cc8-406d-f46dd32c097a@iki.fi> Trees that grow is essentially this, but using type families. data Foo ksi = LeftFoo !(XLeftFoo ksi) !A | RightFoo !(XRightFoo ksi) !B type family XLeftFoo ksi :: Type type family XRightFoo ksi :: Type Then you can define data Both type instance XLeftFoo Both = () type instance XRightFoo Both = () or data OnlyLeft type instance XLeftFoo OnlyLeft = () type instance XRightFoo OnlyLeft = Void --- Third option is to simply have parametrized data: data Foo b = LeftFoo !A | RIghtFoo !b type FooBoth = Foo B type FooOnlyLeft = Foo Void --- Sometimes I prefer a higher-kinded data approach, especially if there is very little variants needed, and they are "uniform" (e.g. second variant doesn't have some fields). Yet, sometimes simple parameterized data is simplest approach (especially as you get stuff for free by deriving Traversable!). On the other hand, if type is big and have many uniform extension points (even if there are few different combinations), then HKD becomes boilerplate heavy as well. The drawback of TTG, is that writing polymorphic code (i.e. which work for any or some `ksi`s) is not very fun: a lot of equality constraints etc. - Oleg On 30.8.2022 16.30, Olaf Klinke wrote: > Dear Café, > > Is there prior art/existing packages for the following? Is it maybefunctional programming folklore? Is it a sign of bad program design? > Sometimes I feel the need to selectively allow or disallow alternatives > in a sum type. That is, suppose we have a sum type > > data Foo = LeftFoo !A | RightFoo !B > > and at some places in the program we want the type system to enforce > that only the constructor LeftFoo can be used. My solution would be to > use a strict version of Data.Functor.Const and make the type higher > rank: > > newtype Const' a b = Const' !a > -- Const' Void b ~ Void > -- Const' () b ~ () > > data Foo' f = LeftFoo' !A | RightFoo' !(f B) > type Foo = Foo' Identity > type LeftFoo = Foo' (Const' Void) -- can not construct a RightFoo' > > The advantage over defining LeftFoo as an entirely different type is > that Foo and LeftFoo can share functions operating entirely on the left > option. > > Olaf > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. From lemming at henning-thielemann.de Tue Aug 30 14:46:26 2022 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Tue, 30 Aug 2022 16:46:26 +0200 (CEST) Subject: [Haskell-cafe] selectively allow alternatives in a sum type In-Reply-To: <9c38c719bc507fbde3109d026bc6ed639e86af63.camel@aatal-apotheke.de> References: <9c38c719bc507fbde3109d026bc6ed639e86af63.camel@aatal-apotheke.de> Message-ID: On Tue, 30 Aug 2022, Olaf Klinke wrote: > Is there prior art/existing packages for the following? Is it maybefunctional programming folklore? Is it a sign of bad program design? > Sometimes I feel the need to selectively allow or disallow alternatives > in a sum type. That is, suppose we have a sum type > > data Foo = LeftFoo !A | RightFoo !B > > and at some places in the program we want the type system to enforce > that only the constructor LeftFoo can be used. We could use a type variable and type classes. f :: (ContainsA x) => ... x ... g :: (ContainsA x, ContainsB x) => ... x ... where the classes ContainsA and ContainsB provide accessors to the summands. Then x could be either A or B or Either A B and so on and there would be instances instance ContainsA A instance ContainsB B instance (a ~ A) => ContainsA (Either a b) instance (b ~ B) => ContainsB (Either a b) From sylvain at haskus.fr Tue Aug 30 14:49:59 2022 From: sylvain at haskus.fr (Sylvain Henry) Date: Tue, 30 Aug 2022 16:49:59 +0200 Subject: [Haskell-cafe] selectively allow alternatives in a sum type In-Reply-To: <9c38c719bc507fbde3109d026bc6ed639e86af63.camel@aatal-apotheke.de> References: <9c38c719bc507fbde3109d026bc6ed639e86af63.camel@aatal-apotheke.de> Message-ID: <9b6bf563-d646-1510-fbe9-9e7a766d8746@haskus.fr> Hi, In this specific case you could use a GADT: data Foo (only_left :: Bool) where LeftFoo :: A -> Foo only_left RightFoo :: B -> Foo 'False onlyLeft :: Foo 'True -> String onlyLeft = \case LeftFoo _a -> "an A" anyFoo :: Foo a -> String anyFoo = \case LeftFoo _a -> "an A" RightFoo _b -> "a B" But it isn't very modular. A more heavyweight alternative is to use some kind of variants instead. See https://docs.haskus.org/variant.html for example where I describe my implementation. I wish we had more compiler support for constructor polymorphism like this though. Sylvain On 30/08/2022 15:30, Olaf Klinke wrote: > Dear Café, > > Is there prior art/existing packages for the following? Is it maybefunctional programming folklore? Is it a sign of bad program design? > Sometimes I feel the need to selectively allow or disallow alternatives > in a sum type. That is, suppose we have a sum type > > data Foo = LeftFoo !A | RightFoo !B > > and at some places in the program we want the type system to enforce > that only the constructor LeftFoo can be used. My solution would be to > use a strict version of Data.Functor.Const and make the type higher > rank: > > newtype Const' a b = Const' !a > -- Const' Void b ~ Void > -- Const' () b ~ () > > data Foo' f = LeftFoo' !A | RightFoo' !(f B) > type Foo = Foo' Identity > type LeftFoo = Foo' (Const' Void) -- can not construct a RightFoo' > > The advantage over defining LeftFoo as an entirely different type is > that Foo and LeftFoo can share functions operating entirely on the left > option. > > Olaf > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. From david.feuer at gmail.com Tue Aug 30 15:09:12 2022 From: david.feuer at gmail.com (David Feuer) Date: Tue, 30 Aug 2022 11:09:12 -0400 Subject: [Haskell-cafe] selectively allow alternatives in a sum type In-Reply-To: <9c38c719bc507fbde3109d026bc6ed639e86af63.camel@aatal-apotheke.de> References: <9c38c719bc507fbde3109d026bc6ed639e86af63.camel@aatal-apotheke.de> Message-ID: One downside of this *particular* formulation is that it doesn't play well with Coercible. On Tue, Aug 30, 2022, 9:31 AM Olaf Klinke wrote: > Dear Café, > > Is there prior art/existing packages for the following? Is it > maybefunctional programming folklore? Is it a sign of bad program design? > Sometimes I feel the need to selectively allow or disallow alternatives > in a sum type. That is, suppose we have a sum type > > data Foo = LeftFoo !A | RightFoo !B > > and at some places in the program we want the type system to enforce > that only the constructor LeftFoo can be used. My solution would be to > use a strict version of Data.Functor.Const and make the type higher > rank: > > newtype Const' a b = Const' !a > -- Const' Void b ~ Void > -- Const' () b ~ () > > data Foo' f = LeftFoo' !A | RightFoo' !(f B) > type Foo = Foo' Identity > type LeftFoo = Foo' (Const' Void) -- can not construct a RightFoo' > > The advantage over defining LeftFoo as an entirely different type is > that Foo and LeftFoo can share functions operating entirely on the left > option. > > Olaf > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From will.yager at gmail.com Tue Aug 30 20:53:08 2022 From: will.yager at gmail.com (William Yager) Date: Tue, 30 Aug 2022 16:53:08 -0400 Subject: [Haskell-cafe] selectively allow alternatives in a sum type In-Reply-To: References: <9c38c719bc507fbde3109d026bc6ed639e86af63.camel@aatal-apotheke.de> Message-ID: In university, I wrote a bunch of CPUs in clash/haskell for an FPGA CPU design class. In one pipelined scalar CPU, I had a number of CPU instructions, and as the instructions moved down the pipe, the set of allowed instructions would change. E.g. a memory read instruction would eventually get changed to a register write instruction, and there was no reason to permit a memory read instruction to be representable after the memory read stage of the pipeline. I vaguely recall using a GADT+typeclass strategy something like this to check this at compile time: data Stage = F | D | R | X -- fetch/decode/read/execute data Instruction allowed where MemRead :: MemAddress -> Register -> Instruction [F,D,R] RegWrite :: Word64 -> Register -> Instruction [F,D,R,X] ... -- Type-level list membership executeR :: (Contains R in, Contains X out) => ReadContext -> Instruction in -> (ReadResult, Instruction out) executeR ctx (MemRead a r) = ... executeR ctx (RegWrite w r) = ... executeX :: Contains X in => ExecutionContext -> Instruction in -> ExecutionResult executeX ctx (RegWrite w r) = ... If I'm remembering this correctly, Haskell's `GADTs meet their match` based type checker was smart enough to know when a constructor was not allowed for a function, and would not give me spurious exhaustiveness warnings. I think I had another strategy still using typeclasses, but not using type-level lists/sets, but I can't remember what it would have been. Will On Tue, Aug 30, 2022 at 11:09 AM David Feuer wrote: > One downside of this *particular* formulation is that it doesn't play well > with Coercible. > > On Tue, Aug 30, 2022, 9:31 AM Olaf Klinke wrote: > >> Dear Café, >> >> Is there prior art/existing packages for the following? Is it >> maybefunctional programming folklore? Is it a sign of bad program design? >> Sometimes I feel the need to selectively allow or disallow alternatives >> in a sum type. That is, suppose we have a sum type >> >> data Foo = LeftFoo !A | RightFoo !B >> >> and at some places in the program we want the type system to enforce >> that only the constructor LeftFoo can be used. My solution would be to >> use a strict version of Data.Functor.Const and make the type higher >> rank: >> >> newtype Const' a b = Const' !a >> -- Const' Void b ~ Void >> -- Const' () b ~ () >> >> data Foo' f = LeftFoo' !A | RightFoo' !(f B) >> type Foo = Foo' Identity >> type LeftFoo = Foo' (Const' Void) -- can not construct a RightFoo' >> >> The advantage over defining LeftFoo as an entirely different type is >> that Foo and LeftFoo can share functions operating entirely on the left >> option. >> >> Olaf >> >> _______________________________________________ >> Haskell-Cafe mailing list >> To (un)subscribe, modify options or view archives go to: >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> Only members subscribed via the mailman list are allowed to post. > > _______________________________________________ > 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 carter.schonwald at gmail.com Tue Aug 30 21:35:29 2022 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Tue, 30 Aug 2022 17:35:29 -0400 Subject: [Haskell-cafe] Package takeover request for fgl In-Reply-To: <87y1v65522.fsf@sigkill.dk> References: <87y1v65522.fsf@sigkill.dk> Message-ID: you should perhaps first engage with hackage trustees to do a NMU bug fix, and then do the takeover process once things are more stable? On Tue, Aug 30, 2022 at 7:45 AM Troels Henriksen wrote: > I am requesting to take over the package fgl: > > https://hackage.haskell.org/package/fgl > > It is currently broken in GHC 9.4, which is fixed by this pull request: > https://github.com/haskell/fgl/pull/104 > > The maintainer Ivan Miljenovic has not been active on GitHub since > January. I wrote Ivan on August 12th offering to help out with > maintenance, but have received no response yet. > > The package is part of the 'haskell' organisation on GitHub. I don't > know whether that is supposed to signify some kind of "community > maintenance" (it appears Ivan is not the original author of fgl), but I > would eventually need Hackage upload rights as well. > _______________________________________________ > 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 olf at aatal-apotheke.de Wed Aug 31 10:27:25 2022 From: olf at aatal-apotheke.de (Olaf Klinke) Date: Wed, 31 Aug 2022 12:27:25 +0200 Subject: [Haskell-cafe] selectively allow alternatives in a sum type Message-ID: > Dear Café, > > Is there prior art/existing packages for the following? Is it maybe functional programming folklore? Is it a sign of bad program design? > Sometimes I feel the need to selectively allow or disallow alternatives > in a sum type. That is, suppose we have a sum type > > data Foo = LeftFoo !A | RightFoo !B > > and at some places in the program we want the type system to enforce > that only the constructor LeftFoo can be used. My solution would be to > make the type higher rank: > > data Foo' f = LeftFoo' !A | RightFoo' !(f B) > type Foo = Foo' Identity > type LeftFoo = Foo' (Const' Void) -- can not construct a RightFoo' > > The advantage over defining LeftFoo as an entirely different type is > that Foo and LeftFoo can share functions operating entirely on the left > option. > > Olaf Henning and Will both suggested accessor type classes. I am fond of my solution because it uses plain algebraic data types, no classes, GADTs or type-level lists. David, can you elaborate how this collides with Coercible? What surprised me is that when writing a function f :: LeftFoo -> r GHC did not warn me (-Wincomplete-patterns) about missing cases when f only uses the LeftFoo' pattern match. Hence the fact that RightFoo' :: Const Void B -> LeftFoo is the empty function must somehow be known to the compiler. Nice! Olaf From jgbm at acm.org Wed Aug 31 19:19:33 2022 From: jgbm at acm.org (J. Garrett Morris) Date: Wed, 31 Aug 2022 14:19:33 -0500 Subject: [Haskell-cafe] STATUS_DLL_NOT_FOUND from HLS 1.7 on Windows 10/11 Message-ID: Dear cafe, A few of my students have encountered a problem running HLS 1.7 on Windows 10/11. Their Haskell installations mostly seem okay---everything installed by `ghcup` (1.8) , and `cabal` (3.6.2) and `ghc` (9.2.2) work as expected. However, when VS Code (via the Haskell plugin) attempts to start the language server, it exits repeatedly with error STATUS_DLL_NOT_FOUND (or its signed integer equivalent). Has anyone encountered a configuration that leads to this problem before? Most of the students are not having this problem (nor am I, on similar software configurations), so I suspect it's a consequence of something else they have installed. Thanks, /g -- Prosperum ac felix scelus virtus vocatur -- Seneca -------------- next part -------------- An HTML attachment was scrubbed... URL: From olf at aatal-apotheke.de Wed Aug 31 20:48:02 2022 From: olf at aatal-apotheke.de (Olaf Klinke) Date: Wed, 31 Aug 2022 22:48:02 +0200 Subject: [Haskell-cafe] selectively allow alternatives in a sum type Message-ID: > Trees that grow is essentially this, but using type families. > > data Foo ksi > = LeftFoo !(XLeftFoo ksi) !A > | RightFoo !(XRightFoo ksi) !B > > type family XLeftFoo ksi :: Type > type family XRightFoo ksi :: Type > > Then you can define > > data Both > type instance XLeftFoo Both = () > type instance XRightFoo Both = () > > or > > data OnlyLeft > type instance XLeftFoo OnlyLeft = () > type instance XRightFoo OnlyLeft = Void > > --- > > Third option is to simply have parametrized data: > > data Foo b > = LeftFoo !A > | RIghtFoo !b > > type FooBoth = Foo B > type FooOnlyLeft = Foo Void > > --- > > Sometimes I prefer a higher-kinded data approach, especially if there is > very little variants needed, and they are "uniform" (e.g. second variant > doesn't have some fields). > Yet, sometimes simple parameterized data is simplest approach > (especially as you get stuff for free by deriving Traversable!). > > On the other hand, if type is big and have many uniform extension points > (even if there are few different combinations), then HKD becomes > boilerplate heavy as well. > The drawback of TTG, is that writing polymorphic code (i.e. which work > for any or some `ksi`s) is not very fun: a lot of equality constraints etc. > > - Oleg So I re-discovered Trees that Grow sans the trick of using type families to name particular combinations of parameters. Hooray Najd, and thanks Oleg for bringing this up. Olaf From david.feuer at gmail.com Wed Aug 31 22:25:32 2022 From: david.feuer at gmail.com (David Feuer) Date: Wed, 31 Aug 2022 18:25:32 -0400 Subject: [Haskell-cafe] selectively allow alternatives in a sum type In-Reply-To: References: Message-ID: To avoid actually realizing those boring fields in memory, use an unlifted newtype. type VoidUnit# :: TYPE ('TupleRep '[]) newtype VoidUnit# = VoidUnit# VoidUnit# absurd# :: VoidUnit# -> a absurd# (VoidUnit# v) = absurd# v Unfortunately, GHC's pattern checker isn't smart enough to see by itself that VoidUnit# is uninhabited, even though that's pretty obvious to a human. TTG also has coercion problems thanks to the type families. *Sigh* On Wed, Aug 31, 2022, 4:48 PM Olaf Klinke wrote: > > Trees that grow is essentially this, but using type families. > > > > data Foo ksi > > = LeftFoo !(XLeftFoo ksi) !A > > | RightFoo !(XRightFoo ksi) !B > > > > type family XLeftFoo ksi :: Type > > type family XRightFoo ksi :: Type > > > > Then you can define > > > > data Both > > type instance XLeftFoo Both = () > > type instance XRightFoo Both = () > > > > or > > > > data OnlyLeft > > type instance XLeftFoo OnlyLeft = () > > type instance XRightFoo OnlyLeft = Void > > > > --- > > > > Third option is to simply have parametrized data: > > > > data Foo b > > = LeftFoo !A > > | RIghtFoo !b > > > > type FooBoth = Foo B > > type FooOnlyLeft = Foo Void > > > > --- > > > > Sometimes I prefer a higher-kinded data approach, especially if there is > > very little variants needed, and they are "uniform" (e.g. second variant > > doesn't have some fields). > > Yet, sometimes simple parameterized data is simplest approach > > (especially as you get stuff for free by deriving Traversable!). > > > > On the other hand, if type is big and have many uniform extension points > > (even if there are few different combinations), then HKD becomes > > boilerplate heavy as well. > > The drawback of TTG, is that writing polymorphic code (i.e. which work > > for any or some `ksi`s) is not very fun: a lot of equality constraints > etc. > > > > - Oleg > > So I re-discovered Trees that Grow sans the trick of using type > families to name particular combinations of parameters. Hooray Najd, > and thanks Oleg for bringing this up. > > Olaf > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: