| 2025-04-01 00:01:54 +0200 | dhil | (~dhil@2a0c:b381:52e:3600:1143:d61d:a64d:dc67) (Ping timeout: 246 seconds) |
| 2025-04-01 00:02:30 +0200 | ljdarj1 | (~Thunderbi@user/ljdarj) ljdarj |
| 2025-04-01 00:02:37 +0200 | weary-traveler | (~user@user/user363627) user363627 |
| 2025-04-01 00:02:52 +0200 | L29Ah | (~L29Ah@wikipedia/L29Ah) L29Ah |
| 2025-04-01 00:06:11 +0200 | ljdarj | (~Thunderbi@user/ljdarj) (Ping timeout: 268 seconds) |
| 2025-04-01 00:06:11 +0200 | ljdarj1 | ljdarj |
| 2025-04-01 00:08:43 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-04-01 00:13:42 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
| 2025-04-01 00:20:31 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-04-01 00:20:54 +0200 | manny69 | (~manny@2601:445:700:69b0:edc8:140b:9839:8c7d) (Ping timeout: 240 seconds) |
| 2025-04-01 00:23:15 +0200 | tromp | (~textual@2001:1c00:3487:1b00:29bc:7fae:9d9f:d545) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2025-04-01 00:25:26 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
| 2025-04-01 00:26:13 +0200 | remexre | (~remexre@user/remexre) (Ping timeout: 245 seconds) |
| 2025-04-01 00:27:10 +0200 | Eoco | (~ian@128.101.131.218) (Ping timeout: 244 seconds) |
| 2025-04-01 00:27:17 +0200 | jespada | (~jespada@2800:a4:2231:f700:8971:aafc:a22d:7172) (Quit: My Mac has gone to sleep. ZZZzzz…) |
| 2025-04-01 00:34:00 +0200 | Smiles | (uid551636@id-551636.lymington.irccloud.com) Smiles |
| 2025-04-01 00:34:47 +0200 | Eoco | (~ian@128.101.131.218) Eoco |
| 2025-04-01 00:36:20 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-04-01 00:36:46 +0200 | remexre | (~remexre@user/remexre) remexre |
| 2025-04-01 00:38:48 +0200 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) peterbecich |
| 2025-04-01 00:40:49 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 244 seconds) |
| 2025-04-01 00:52:03 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-04-01 00:54:14 +0200 | Sgeo | (~Sgeo@user/sgeo) Sgeo |
| 2025-04-01 00:57:00 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 265 seconds) |
| 2025-04-01 01:02:00 +0200 | ljdarj | (~Thunderbi@user/ljdarj) (Ping timeout: 244 seconds) |
| 2025-04-01 01:07:49 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-04-01 01:09:29 +0200 | toby-bro | (~toby-bro@user/toby-bro) (Ping timeout: 260 seconds) |
| 2025-04-01 01:12:44 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
| 2025-04-01 01:21:33 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-04-01 01:25:02 +0200 | cptaffe | (~cptaffe@user/cptaffe) (Ping timeout: 265 seconds) |
| 2025-04-01 01:27:50 +0200 | ft | (~ft@p508db463.dip0.t-ipconnect.de) (Quit: Lost terminal) |
| 2025-04-01 01:28:18 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 245 seconds) |
| 2025-04-01 01:30:56 +0200 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 244 seconds) |
| 2025-04-01 01:37:45 +0200 | xff0x | (~xff0x@2405:6580:b080:900:1654:70d2:c294:d90) (Quit: xff0x) |
| 2025-04-01 01:38:31 +0200 | sprotte24 | (~sprotte24@p200300d16f24f500b1cefbd2da3b16f9.dip0.t-ipconnect.de) (Quit: Leaving) |
| 2025-04-01 01:38:59 +0200 | sprotte24 | (~sprotte24@p200300d16f24f500b1cefbd2da3b16f9.dip0.t-ipconnect.de) |
| 2025-04-01 01:39:24 +0200 | sprotte24 | (~sprotte24@p200300d16f24f500b1cefbd2da3b16f9.dip0.t-ipconnect.de) (Client Quit) |
| 2025-04-01 01:39:36 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-04-01 01:40:30 +0200 | Pixi` | (~Pixi@user/pixi) Pixi |
| 2025-04-01 01:40:39 +0200 | Tuplanolla | (~Tuplanoll@91-159-69-59.elisa-laajakaista.fi) (Quit: Leaving.) |
| 2025-04-01 01:42:18 +0200 | ft | (~ft@p508db463.dip0.t-ipconnect.de) ft |
| 2025-04-01 01:42:26 +0200 | forell | (~forell@user/forell) (Ping timeout: 265 seconds) |
| 2025-04-01 01:43:38 +0200 | Pixi | (~Pixi@user/pixi) (Ping timeout: 244 seconds) |
| 2025-04-01 01:43:53 +0200 | acidjnk_new | (~acidjnk@p200300d6e71c4f027cb63b5a22c835f3.dip0.t-ipconnect.de) acidjnk |
| 2025-04-01 01:44:37 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
| 2025-04-01 01:47:03 +0200 | acidjnk | (~acidjnk@p200300d6e71c4f0205a1013c182d2742.dip0.t-ipconnect.de) (Ping timeout: 245 seconds) |
| 2025-04-01 01:49:09 +0200 | acidjnk_new | (~acidjnk@p200300d6e71c4f027cb63b5a22c835f3.dip0.t-ipconnect.de) (Ping timeout: 248 seconds) |
| 2025-04-01 01:52:43 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-04-01 01:57:09 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 248 seconds) |
| 2025-04-01 01:57:54 +0200 | xff0x | (~xff0x@ai066236.d.east.v6connect.net) |
| 2025-04-01 02:00:23 +0200 | abrar | (~abrar@static-96-245-187-163.phlapa.fios.verizon.net) (Quit: WeeChat 4.4.3) |
| 2025-04-01 02:00:55 +0200 | unter-oe | (~unter-oe@user/unter-oe) unter-oe |
| 2025-04-01 02:02:14 +0200 | xff0x_ | (~xff0x@ai066236.d.east.v6connect.net) |
| 2025-04-01 02:02:14 +0200 | xff0x | (~xff0x@ai066236.d.east.v6connect.net) (Ping timeout: 252 seconds) |
| 2025-04-01 02:02:29 +0200 | unter-oe | (~unter-oe@user/unter-oe) (Remote host closed the connection) |
| 2025-04-01 02:02:43 +0200 | unter-oe | (~unter-oe@user/unter-oe) unter-oe |
| 2025-04-01 02:07:19 +0200 | ryanbooker | (uid4340@id-4340.hampstead.irccloud.com) ryanbooker |
| 2025-04-01 02:08:05 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-04-01 02:09:53 +0200 | zungi | (~tory@user/andrewchawk) andrewchawk |
| 2025-04-01 02:10:42 +0200 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) peterbecich |
| 2025-04-01 02:10:50 +0200 | She | ShePT |
| 2025-04-01 02:12:54 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 260 seconds) |
| 2025-04-01 02:13:37 +0200 | thorongil | (~thorongil@user/thorongil) thorongil |
| 2025-04-01 02:15:58 +0200 | weary-traveler | (~user@user/user363627) (Remote host closed the connection) |
| 2025-04-01 02:19:19 +0200 | unter-oe | (~unter-oe@user/unter-oe) (Ping timeout: 260 seconds) |
| 2025-04-01 02:23:26 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-04-01 02:26:38 +0200 | <roconnor> | Happy Birthday Haskell |
| 2025-04-01 02:26:42 +0200 | Axma91836 | (~Axman6@user/axman6) Axman6 |
| 2025-04-01 02:28:37 +0200 | Axman6 | (~Axman6@user/axman6) (Ping timeout: 250 seconds) |
| 2025-04-01 02:28:38 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 268 seconds) |
| 2025-04-01 02:32:11 +0200 | catties | CatGPT |
| 2025-04-01 02:34:03 +0200 | abrar | (~abrar@static-96-245-187-163.phlapa.fios.verizon.net) |
| 2025-04-01 02:34:54 +0200 | <EvanR> | haskell was an april fools joke? |
| 2025-04-01 02:39:15 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-04-01 02:40:04 +0200 | <Axma91836> | b/nick Axman6 |
| 2025-04-01 02:40:07 +0200 | Axma91836 | Axman6 |
| 2025-04-01 02:41:38 +0200 | xff0x_ | (~xff0x@ai066236.d.east.v6connect.net) (Quit: xff0x_) |
| 2025-04-01 02:41:59 +0200 | <haskellbridge> | <lowtex> Hey, I'm using NixOS & Cabal & GHC 9.12.1. I want to utilize "hmatrix-gls" (0.19.0.1). But "cabal new-build all --preference="Cabal >= 3.14.1.1" --keep-going --enable-debug-info=3" inside of "nix develop --impure --expr 'with import <nixpkgs> {}; mkShell rec { buildInputs = [pkg-config zlib blas lapack gsl]; LD_LIBRARY_PATH = lib.makeLibraryPath buildInputs;}'" leads to "<no location info>: error: …/libgsl.so:... |
| 2025-04-01 02:42:04 +0200 | <haskellbridge> | ... undefined symbol: cblas_ctrmv". Any idea? Thx in advance! |
| 2025-04-01 02:43:02 +0200 | Smiles | (uid551636@id-551636.lymington.irccloud.com) (Quit: Connection closed for inactivity) |
| 2025-04-01 02:43:44 +0200 | <geekosaur> | might be better off asking in a nix room, but that sounds like the version of blas you're getting isn't supported by the gsl version you're getting |
| 2025-04-01 02:44:03 +0200 | <geekosaur> | and probably unrelated to Haskell |
| 2025-04-01 02:44:08 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 245 seconds) |
| 2025-04-01 02:45:00 +0200 | xff0x | (~xff0x@2405:6580:b080:900:9d42:97ad:e5ba:bd56) |
| 2025-04-01 02:47:03 +0200 | thuna` | (~thuna`@user/thuna/x-1480069) thuna` |
| 2025-04-01 02:48:23 +0200 | <roconnor> | EvanR: yep |
| 2025-04-01 02:48:47 +0200 | otto_s | (~user@p5b044ec8.dip0.t-ipconnect.de) (Ping timeout: 252 seconds) |
| 2025-04-01 02:50:15 +0200 | xff0x | (~xff0x@2405:6580:b080:900:9d42:97ad:e5ba:bd56) (Ping timeout: 246 seconds) |
| 2025-04-01 02:50:24 +0200 | otto_s | (~user@p4ff2724c.dip0.t-ipconnect.de) |
| 2025-04-01 02:51:56 +0200 | <haskellbridge> | <lowtex> Among other things, I've tried to (1) utilize "openblas" instead and to (2) link dynamically "shared: True↵executable-dynamic: True" |
| 2025-04-01 02:51:58 +0200 | <haskellbridge> | @irc_libera.chat_geekosaur:kf8nh.com Thanks for your suggestion, I'll reach out there. But I don't have experience with those tools themselves, so I don't have the basis to attempt to pair some versions haphazardly by myself. |
| 2025-04-01 02:51:59 +0200 | <lambdabot> | Unknown command, try @list |
| 2025-04-01 02:53:09 +0200 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 260 seconds) |
| 2025-04-01 02:53:42 +0200 | malte | (~malte@mal.tc) (Remote host closed the connection) |
| 2025-04-01 02:54:02 +0200 | j1n37- | (~j1n37@user/j1n37) j1n37 |
| 2025-04-01 02:54:56 +0200 | j1n37 | (~j1n37@user/j1n37) (Ping timeout: 244 seconds) |
| 2025-04-01 02:55:03 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-04-01 02:59:30 +0200 | malte | (~malte@mal.tc) malte |
| 2025-04-01 03:01:39 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 244 seconds) |
| 2025-04-01 03:03:39 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-04-01 03:08:22 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 244 seconds) |
| 2025-04-01 03:10:29 +0200 | hgolden | (~hgolden@2603:8000:9d00:3ed1:1b03:b08c:d961:6530) hgolden |
| 2025-04-01 03:11:08 +0200 | notdabs | (~Owner@2600:1700:69cf:9000:6cf0:d644:3911:cb5b) (Quit: Leaving) |
| 2025-04-01 03:13:53 +0200 | hattckory | (~hattckory@bras-base-toroon4524w-grc-30-70-27-118-207.dsl.bell.ca) (Ping timeout: 248 seconds) |
| 2025-04-01 03:18:12 +0200 | CatGPT | catties |
| 2025-04-01 03:19:22 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-04-01 03:20:39 +0200 | hughjfchen | (~hughjfche@vmi2417424.contaboserver.net) (Quit: WeeChat 4.4.3) |
| 2025-04-01 03:21:49 +0200 | hughjfchen | (~hughjfche@vmi2417424.contaboserver.net) hughjfchen |
| 2025-04-01 03:23:43 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 245 seconds) |
| 2025-04-01 03:24:03 +0200 | pavonia | (~user@user/siracusa) (Quit: Bye!) |
| 2025-04-01 03:27:23 +0200 | hattckory | (~hattckory@bras-base-toroon4524w-grc-30-70-27-118-207.dsl.bell.ca) |
| 2025-04-01 03:27:39 +0200 | <monochrom> | I think it goes more meta. There was an April Fool's joke that claimed that Haskell was an April Fool's joke. #ModalLogic |
| 2025-04-01 03:27:40 +0200 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) peterbecich |
| 2025-04-01 03:31:15 +0200 | <EvanR> | April Fools is a monad |
| 2025-04-01 03:31:41 +0200 | <monochrom> | hehe |
| 2025-04-01 03:31:51 +0200 | <EvanR> | multiple burrito layers of joke |
| 2025-04-01 03:32:33 +0200 | hattckory | (~hattckory@bras-base-toroon4524w-grc-30-70-27-118-207.dsl.bell.ca) (Ping timeout: 276 seconds) |
| 2025-04-01 03:34:43 +0200 | thuna` | (~thuna`@user/thuna/x-1480069) (Ping timeout: 244 seconds) |
| 2025-04-01 03:34:44 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-04-01 03:35:14 +0200 | glguy | gLLMguy |
| 2025-04-01 03:36:20 +0200 | hattckory | (~hattckory@bras-base-toroon4524w-grc-30-70-27-118-207.dsl.bell.ca) |
| 2025-04-01 03:39:22 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 244 seconds) |
| 2025-04-01 03:39:28 +0200 | xff0x | (~xff0x@fsb6a9491c.tkyc517.ap.nuro.jp) |
| 2025-04-01 03:46:52 +0200 | thorongil | (~thorongil@user/thorongil) (Quit: leaving) |
| 2025-04-01 03:50:32 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-04-01 03:55:27 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
| 2025-04-01 04:06:22 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-04-01 04:11:29 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 248 seconds) |
| 2025-04-01 04:13:35 +0200 | manny68 | (~manny@2601:445:700:69b0:eea0:8f59:8e82:6460) |
| 2025-04-01 04:16:59 +0200 | ryanbooker | (uid4340@id-4340.hampstead.irccloud.com) (Quit: Connection closed for inactivity) |
| 2025-04-01 04:18:38 +0200 | machinedgod | (~machinedg@d108-173-18-100.abhsia.telus.net) (Ping timeout: 252 seconds) |
| 2025-04-01 04:22:07 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-04-01 04:22:28 +0200 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 245 seconds) |
| 2025-04-01 04:26:39 +0200 | otto_s | (~user@p4ff2724c.dip0.t-ipconnect.de) (Ping timeout: 260 seconds) |
| 2025-04-01 04:27:07 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 244 seconds) |
| 2025-04-01 04:28:02 +0200 | otto_s | (~user@p5b044af5.dip0.t-ipconnect.de) |
| 2025-04-01 04:37:56 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-04-01 04:42:50 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
| 2025-04-01 04:53:43 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-04-01 04:55:40 +0200 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) bitdex |
| 2025-04-01 04:56:58 +0200 | Unicorn_Princess | (~Unicorn_P@user/Unicorn-Princess/x-3540542) Unicorn_Princess |
| 2025-04-01 04:58:44 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 260 seconds) |
| 2025-04-01 05:01:36 +0200 | troydm | (~troydm@user/troydm) (Quit: What is Hope? That all of your wishes and all of your dreams come true? To turn back time because things were not supposed to happen like that (C) Rau Le Creuset) |
| 2025-04-01 05:03:37 +0200 | Garbanzo | (~Garbanzo@2602:304:6eac:dc10::2e) |
| 2025-04-01 05:09:30 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-04-01 05:14:08 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 245 seconds) |
| 2025-04-01 05:16:32 +0200 | gmg | (~user@user/gehmehgeh) (Remote host closed the connection) |
| 2025-04-01 05:19:05 +0200 | a_fantom | (~fantom@2.219.56.221) (Ping timeout: 244 seconds) |
| 2025-04-01 05:19:35 +0200 | gmg | (~user@user/gehmehgeh) gehmehgeh |
| 2025-04-01 05:25:18 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-04-01 05:29:56 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 244 seconds) |
| 2025-04-01 05:38:02 +0200 | michalz | (~michalz@185.246.207.221) |
| 2025-04-01 05:41:04 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-04-01 05:41:32 +0200 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) peterbecich |
| 2025-04-01 05:45:59 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 260 seconds) |
| 2025-04-01 05:56:52 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-04-01 06:05:33 +0200 | zungi | (~tory@user/andrewchawk) (Remote host closed the connection) |
| 2025-04-01 06:05:35 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 244 seconds) |
| 2025-04-01 06:05:58 +0200 | zungi | (~tory@user/andrewchawk) andrewchawk |
| 2025-04-01 06:10:19 +0200 | tavare | (~tavare@150.129.88.189) |
| 2025-04-01 06:10:19 +0200 | tavare | (~tavare@150.129.88.189) (Changing host) |
| 2025-04-01 06:10:19 +0200 | tavare | (~tavare@user/tavare) tavare |
| 2025-04-01 06:11:11 +0200 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 252 seconds) |
| 2025-04-01 06:13:27 +0200 | tavare | (~tavare@user/tavare) (Remote host closed the connection) |
| 2025-04-01 06:13:50 +0200 | tavare | (~tavare@150.129.88.189) tavare |
| 2025-04-01 06:13:50 +0200 | tavare | (~tavare@150.129.88.189) (Changing host) |
| 2025-04-01 06:13:50 +0200 | tavare | (~tavare@user/tavare) tavare |
| 2025-04-01 06:13:54 +0200 | werneta | (~werneta@syn-071-083-160-242.res.spectrum.com) werneta |
| 2025-04-01 06:17:05 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-04-01 06:21:19 +0200 | takuan | (~takuan@d8D86B601.access.telenet.be) |
| 2025-04-01 06:22:17 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 265 seconds) |
| 2025-04-01 06:24:12 +0200 | arahael | (~arahael@user/arahael) arahael |
| 2025-04-01 06:24:54 +0200 | manny68 | (~manny@2601:445:700:69b0:eea0:8f59:8e82:6460) (Quit: Client closed) |
| 2025-04-01 06:32:52 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-04-01 06:37:36 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
| 2025-04-01 06:45:10 +0200 | Flow | (~none@gentoo/developer/flow) (Ping timeout: 268 seconds) |
| 2025-04-01 06:48:40 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-04-01 06:51:06 +0200 | tessier | (~tessier@ec2-184-72-149-67.compute-1.amazonaws.com) (Remote host closed the connection) |
| 2025-04-01 06:53:39 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 260 seconds) |
| 2025-04-01 06:54:00 +0200 | Guest52 | (~Guest52@45.176.88.162) |
| 2025-04-01 06:56:20 +0200 | Googulator18 | (~Googulato@178-164-243-34.pool.digikabel.hu) |
| 2025-04-01 06:57:00 +0200 | Flow | (~none@gentoo/developer/flow) flow |
| 2025-04-01 06:58:09 +0200 | DiegoDD | (~diego1234@93.68.153.20) |
| 2025-04-01 06:59:18 +0200 | Googulator | (~Googulato@2a01-036d-0106-01d5-ac5d-24c1-ad5e-7f2b.pool6.digikabel.hu) (Ping timeout: 240 seconds) |
| 2025-04-01 06:59:22 +0200 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Remote host closed the connection) |
| 2025-04-01 06:59:47 +0200 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) bitdex |
| 2025-04-01 07:03:02 +0200 | DiegoDD | (~diego1234@93.68.153.20) () |
| 2025-04-01 07:04:26 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-04-01 07:09:14 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 260 seconds) |
| 2025-04-01 07:09:20 +0200 | JuanDaugherty | (~juan@user/JuanDaugherty) JuanDaugherty |
| 2025-04-01 07:10:49 +0200 | tessier | (~tessier@ip68-8-117-219.sd.sd.cox.net) tessier |
| 2025-04-01 07:15:40 +0200 | tavare | (~tavare@user/tavare) (Remote host closed the connection) |
| 2025-04-01 07:19:49 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-04-01 07:20:22 +0200 | gAy_Dragon | AI_Dragon |
| 2025-04-01 07:24:37 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 248 seconds) |
| 2025-04-01 07:28:45 +0200 | acidjnk_new | (~acidjnk@p200300d6e71c4f02f52af534a157a189.dip0.t-ipconnect.de) acidjnk |
| 2025-04-01 07:29:27 +0200 | internatetional | (~nate@2400:9800:f3:3e9a:1832:1a71:b57a:106c) internatetional |
| 2025-04-01 07:31:07 +0200 | tessier | (~tessier@ip68-8-117-219.sd.sd.cox.net) (Ping timeout: 252 seconds) |
| 2025-04-01 07:33:08 +0200 | tessier | (~tessier@ip68-8-117-219.sd.sd.cox.net) tessier |
| 2025-04-01 07:34:16 +0200 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) peterbecich |
| 2025-04-01 07:35:22 +0200 | fantom | (~fantom@2.219.56.221) |
| 2025-04-01 07:35:33 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-04-01 07:40:24 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
| 2025-04-01 07:51:21 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-04-01 07:52:30 +0200 | Guest52 | (~Guest52@45.176.88.162) (Ping timeout: 240 seconds) |
| 2025-04-01 07:56:17 +0200 | tabaqui | (~tabaqui@167.71.80.236) tabaqui |
| 2025-04-01 07:58:33 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 268 seconds) |
| 2025-04-01 08:00:12 +0200 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 252 seconds) |
| 2025-04-01 08:02:18 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-04-01 08:02:57 +0200 | acarrico | (~acarrico@pppoe-209-99-221-107.greenmountainaccess.net) (Ping timeout: 276 seconds) |
| 2025-04-01 08:05:26 +0200 | acidjnk_new | (~acidjnk@p200300d6e71c4f02f52af534a157a189.dip0.t-ipconnect.de) (Ping timeout: 272 seconds) |
| 2025-04-01 08:07:09 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 260 seconds) |
| 2025-04-01 08:12:24 +0200 | fp | (~Thunderbi@wireless-86-50-141-186.open.aalto.fi) fp |
| 2025-04-01 08:17:40 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-04-01 08:18:01 +0200 | ChaiTRex | (~ChaiTRex@user/chaitrex) (Remote host closed the connection) |
| 2025-04-01 08:18:33 +0200 | ChaiTRex | (~ChaiTRex@user/chaitrex) ChaiTRex |
| 2025-04-01 08:21:47 +0200 | Garbanzo | (~Garbanzo@2602:304:6eac:dc10::2e) (Remote host closed the connection) |
| 2025-04-01 08:22:30 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 244 seconds) |
| 2025-04-01 08:27:54 +0200 | ash3en | (~Thunderbi@149.222.150.125) ash3en |
| 2025-04-01 08:28:09 +0200 | rit | (~rit@2409:40e0:101e:42e7:7902:df58:e4a3:373b) |
| 2025-04-01 08:32:48 +0200 | JuanDaugherty | (~juan@user/JuanDaugherty) (Quit: praxis.meansofproduction.biz (juan@acm.org)) |
| 2025-04-01 08:33:26 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-04-01 08:36:02 +0200 | sroso | (~sroso@user/SrOso) (Ping timeout: 252 seconds) |
| 2025-04-01 08:38:13 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 248 seconds) |
| 2025-04-01 08:42:00 +0200 | jjhoo | (~jahakala@user/jjhoo) (Ping timeout: 252 seconds) |
| 2025-04-01 08:47:48 +0200 | sord937 | (~sord937@gateway/tor-sasl/sord937) sord937 |
| 2025-04-01 08:48:11 +0200 | chele | (~chele@user/chele) chele |
| 2025-04-01 08:49:14 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-04-01 08:54:00 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
| 2025-04-01 08:54:04 +0200 | tromp | (~textual@2001:1c00:3487:1b00:29bc:7fae:9d9f:d545) |
| 2025-04-01 08:56:52 +0200 | CiaoSen | (~Jura@2a02:8071:64e1:da0:5a47:caff:fe78:33db) CiaoSen |
| 2025-04-01 09:00:01 +0200 | caconym | (~caconym@user/caconym) (Quit: bye) |
| 2025-04-01 09:01:31 +0200 | caconym | (~caconym@user/caconym) caconym |
| 2025-04-01 09:03:17 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-04-01 09:06:09 +0200 | acarrico | (~acarrico@pppoe-209-99-221-107.greenmountainaccess.net) |
| 2025-04-01 09:08:51 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 268 seconds) |
| 2025-04-01 09:16:17 +0200 | jmcantrell | (~weechat@user/jmcantrell) (Ping timeout: 265 seconds) |
| 2025-04-01 09:16:38 +0200 | Lord_of_Life_ | (~Lord@user/lord-of-life/x-2819915) Lord_of_Life |
| 2025-04-01 09:16:39 +0200 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) (Ping timeout: 246 seconds) |
| 2025-04-01 09:18:01 +0200 | Lord_of_Life_ | Lord_of_Life |
| 2025-04-01 09:19:20 +0200 | jjhoo | (~jahakala@user/jjhoo) jjhoo |
| 2025-04-01 09:22:18 +0200 | ft | (~ft@p508db463.dip0.t-ipconnect.de) (Quit: leaving) |
| 2025-04-01 09:22:30 +0200 | rit | (~rit@2409:40e0:101e:42e7:7902:df58:e4a3:373b) (Ping timeout: 240 seconds) |
| 2025-04-01 09:25:52 +0200 | internatetional | (~nate@2400:9800:f3:3e9a:1832:1a71:b57a:106c) (Ping timeout: 272 seconds) |
| 2025-04-01 09:35:17 +0200 | internatetional | (~nate@2400:9800:f2:615e:1832:218b:fe6e:8b1a) internatetional |
| 2025-04-01 09:38:09 +0200 | tzh | (~tzh@c-76-115-131-146.hsd1.or.comcast.net) (Quit: zzz) |
| 2025-04-01 09:39:54 +0200 | fp | (~Thunderbi@wireless-86-50-141-186.open.aalto.fi) (Ping timeout: 260 seconds) |
| 2025-04-01 09:41:44 +0200 | j1n37- | (~j1n37@user/j1n37) (Read error: Connection reset by peer) |
| 2025-04-01 09:44:42 +0200 | j1n37 | (~j1n37@user/j1n37) j1n37 |
| 2025-04-01 09:45:58 +0200 | acidjnk_new | (~acidjnk@p200300d6e71c4f8289e7d3d4c6144767.dip0.t-ipconnect.de) acidjnk |
| 2025-04-01 09:46:46 +0200 | emmanuelux | (~emmanuelu@user/emmanuelux) (Read error: Connection reset by peer) |
| 2025-04-01 09:49:32 +0200 | Sgeo | (~Sgeo@user/sgeo) (Read error: Connection reset by peer) |
| 2025-04-01 09:55:19 +0200 | machinedgod | (~machinedg@d108-173-18-100.abhsia.telus.net) machinedgod |
| 2025-04-01 09:55:36 +0200 | zmt00 | (~zmt00@user/zmt00) (Ping timeout: 252 seconds) |
| 2025-04-01 09:58:39 +0200 | Square | (~Square4@user/square) Square |
| 2025-04-01 09:59:07 +0200 | aforemny | (~aforemny@2001:9e8:6cf8:6c00:d3fe:9b53:2e36:ee7b) aforemny |
| 2025-04-01 09:59:28 +0200 | <hellwolf> | I just made a categorical rewrite of base, called catbase, where you can write program such as "main :: forall k. k Void (IO ())" which produces a IO effect in the category k. This allows you to write a runtime completely in rust and optimizes the f out of the generated giant morphism, including using AVX/NEON instructions for all tight loops. |
| 2025-04-01 09:59:28 +0200 | <hellwolf> | The best part is, it is the April fool's day. |
| 2025-04-01 10:04:16 +0200 | merijn | (~merijn@77.242.116.146) merijn |
| 2025-04-01 10:06:24 +0200 | ash3en | (~Thunderbi@149.222.150.125) (Ping timeout: 272 seconds) |
| 2025-04-01 10:15:35 +0200 | unter-oe | (~unter-oe@176.192.243.31) unter-oe |
| 2025-04-01 10:15:35 +0200 | unter-oe | (~unter-oe@176.192.243.31) (Changing host) |
| 2025-04-01 10:15:35 +0200 | unter-oe | (~unter-oe@user/unter-oe) unter-oe |
| 2025-04-01 10:16:19 +0200 | ash3en | (~Thunderbi@149.222.150.125) ash3en |
| 2025-04-01 10:16:33 +0200 | unter-oe | (~unter-oe@user/unter-oe) (Remote host closed the connection) |
| 2025-04-01 10:18:08 +0200 | pavonia | (~user@user/siracusa) siracusa |
| 2025-04-01 10:19:33 +0200 | merijn | (~merijn@77.242.116.146) (Ping timeout: 245 seconds) |
| 2025-04-01 10:23:03 +0200 | lisbeths | (uid135845@id-135845.lymington.irccloud.com) lisbeths |
| 2025-04-01 10:27:36 +0200 | merijn | (~merijn@77.242.116.146) merijn |
| 2025-04-01 10:28:09 +0200 | unter-oe | (~unter-oe@176.192.243.31) |
| 2025-04-01 10:28:09 +0200 | unter-oe | (~unter-oe@176.192.243.31) (Changing host) |
| 2025-04-01 10:28:09 +0200 | unter-oe | (~unter-oe@user/unter-oe) unter-oe |
| 2025-04-01 10:33:44 +0200 | ash3en | (~Thunderbi@149.222.150.125) (Ping timeout: 252 seconds) |
| 2025-04-01 10:39:29 +0200 | unter-oe | (~unter-oe@user/unter-oe) (Remote host closed the connection) |
| 2025-04-01 10:39:43 +0200 | unter-oe | (~unter-oe@user/unter-oe) unter-oe |
| 2025-04-01 10:39:47 +0200 | unter-oe | (~unter-oe@user/unter-oe) (Remote host closed the connection) |
| 2025-04-01 10:43:55 +0200 | <tomsmeding> | hellwolf: I feel like https://github.com/compiling-to-categories/concat unironically tries to do that, apart from the Rust |
| 2025-04-01 10:46:53 +0200 | Smiles | (uid551636@id-551636.lymington.irccloud.com) Smiles |
| 2025-04-01 10:47:52 +0200 | ash3en | (~Thunderbi@149.222.150.125) ash3en |
| 2025-04-01 10:52:25 +0200 | ash3en | (~Thunderbi@149.222.150.125) (Ping timeout: 252 seconds) |
| 2025-04-01 10:53:36 +0200 | califax | (~califax@user/califx) (Ping timeout: 264 seconds) |
| 2025-04-01 10:54:00 +0200 | lxsameer | (~lxsameer@Serene/lxsameer) lxsameer |
| 2025-04-01 10:54:13 +0200 | califax | (~califax@user/califx) califx |
| 2025-04-01 10:56:50 +0200 | fp | (~Thunderbi@wireless-86-50-141-186.open.aalto.fi) fp |
| 2025-04-01 11:07:49 +0200 | internatetional | (~nate@2400:9800:f2:615e:1832:218b:fe6e:8b1a) (Ping timeout: 260 seconds) |
| 2025-04-01 11:18:58 +0200 | dhil | (~dhil@2a0c:b381:52e:3600:a9d5:fde7:3316:82e2) dhil |
| 2025-04-01 11:22:33 +0200 | ash3en | (~Thunderbi@149.222.150.125) ash3en |
| 2025-04-01 11:24:24 +0200 | <hellwolf> | :) Make april fool the day of radical innovation |
| 2025-04-01 11:27:04 +0200 | ash3en | (~Thunderbi@149.222.150.125) (Ping timeout: 260 seconds) |
| 2025-04-01 11:35:19 +0200 | internatetional | (~nate@2400:9800:170:c23:1:0:419:21ae) internatetional |
| 2025-04-01 11:57:42 +0200 | jathan | (~jathan@69.61.93.38) (Ping timeout: 252 seconds) |
| 2025-04-01 12:00:51 +0200 | m5zs7k | (aquares@web10.mydevil.net) (Ping timeout: 276 seconds) |
| 2025-04-01 12:02:49 +0200 | fp | (~Thunderbi@wireless-86-50-141-186.open.aalto.fi) (Ping timeout: 260 seconds) |
| 2025-04-01 12:02:59 +0200 | j1n37- | (~j1n37@user/j1n37) j1n37 |
| 2025-04-01 12:04:05 +0200 | j1n37 | (~j1n37@user/j1n37) (Ping timeout: 248 seconds) |
| 2025-04-01 12:15:01 +0200 | unter-oe | (~unter-oe@176.192.243.31) |
| 2025-04-01 12:15:01 +0200 | unter-oe | (~unter-oe@176.192.243.31) (Changing host) |
| 2025-04-01 12:15:01 +0200 | unter-oe | (~unter-oe@user/unter-oe) unter-oe |
| 2025-04-01 12:20:26 +0200 | m5zs7k | (aquares@web10.mydevil.net) m5zs7k |
| 2025-04-01 12:21:04 +0200 | unter-oe | (~unter-oe@user/unter-oe) (Remote host closed the connection) |
| 2025-04-01 12:22:55 +0200 | unter-oe | (~unter-oe@176.192.243.31) unter-oe |
| 2025-04-01 12:22:55 +0200 | unter-oe | (~unter-oe@176.192.243.31) (Changing host) |
| 2025-04-01 12:22:55 +0200 | unter-oe | (~unter-oe@user/unter-oe) unter-oe |
| 2025-04-01 12:23:09 +0200 | forell | (~forell@user/forell) forell |
| 2025-04-01 12:23:39 +0200 | sord937 | (~sord937@gateway/tor-sasl/sord937) (Remote host closed the connection) |
| 2025-04-01 12:23:50 +0200 | merijn | (~merijn@77.242.116.146) (Ping timeout: 272 seconds) |
| 2025-04-01 12:24:11 +0200 | sord937 | (~sord937@gateway/tor-sasl/sord937) sord937 |
| 2025-04-01 12:26:22 +0200 | xff0x | (~xff0x@fsb6a9491c.tkyc517.ap.nuro.jp) (Ping timeout: 244 seconds) |
| 2025-04-01 12:26:32 +0200 | fp | (~Thunderbi@2001:708:150:10::1d80) fp |
| 2025-04-01 12:27:12 +0200 | unter-oe | (~unter-oe@user/unter-oe) (Remote host closed the connection) |
| 2025-04-01 12:27:33 +0200 | unter-oe | (~unter-oe@176.192.243.31) |
| 2025-04-01 12:27:33 +0200 | unter-oe | (~unter-oe@176.192.243.31) (Changing host) |
| 2025-04-01 12:27:33 +0200 | unter-oe | (~unter-oe@user/unter-oe) unter-oe |
| 2025-04-01 12:29:10 +0200 | unter-oe | (~unter-oe@user/unter-oe) (Remote host closed the connection) |
| 2025-04-01 12:30:46 +0200 | merijn | (~merijn@77.242.116.146) merijn |
| 2025-04-01 12:31:24 +0200 | unter-oe | (~unter-oe@user/unter-oe) unter-oe |
| 2025-04-01 12:35:09 +0200 | merijn | (~merijn@77.242.116.146) (Ping timeout: 244 seconds) |
| 2025-04-01 12:42:17 +0200 | lisbeths | (uid135845@id-135845.lymington.irccloud.com) (Quit: Connection closed for inactivity) |
| 2025-04-01 12:48:00 +0200 | merijn | (~merijn@77.242.116.146) merijn |
| 2025-04-01 12:50:46 +0200 | sord937 | (~sord937@gateway/tor-sasl/sord937) (Remote host closed the connection) |
| 2025-04-01 12:51:06 +0200 | sord937 | (~sord937@gateway/tor-sasl/sord937) sord937 |
| 2025-04-01 12:52:05 +0200 | acidjnk_new | (~acidjnk@p200300d6e71c4f8289e7d3d4c6144767.dip0.t-ipconnect.de) (Ping timeout: 248 seconds) |
| 2025-04-01 12:53:50 +0200 | unter-oe | (~unter-oe@user/unter-oe) (Remote host closed the connection) |
| 2025-04-01 12:53:56 +0200 | jathan | (~jathan@69.61.93.38) jathan |
| 2025-04-01 12:54:09 +0200 | acidjnk_new | (~acidjnk@p200300d6e71c4f8289e7d3d4c6144767.dip0.t-ipconnect.de) |
| 2025-04-01 12:54:50 +0200 | ash3en | (~Thunderbi@149.222.150.125) ash3en |
| 2025-04-01 12:58:48 +0200 | internatetional | (~nate@2400:9800:170:c23:1:0:419:21ae) (Quit: CoreIRC for Android - www.coreirc.com) |
| 2025-04-01 12:59:06 +0200 | merijn | (~merijn@77.242.116.146) (Ping timeout: 265 seconds) |
| 2025-04-01 13:00:05 +0200 | caconym | (~caconym@user/caconym) (Quit: bye) |
| 2025-04-01 13:02:20 +0200 | caconym | (~caconym@user/caconym) caconym |
| 2025-04-01 13:05:01 +0200 | merijn | (~merijn@77.242.116.146) merijn |
| 2025-04-01 13:06:01 +0200 | Smiles | (uid551636@id-551636.lymington.irccloud.com) (Quit: Connection closed for inactivity) |
| 2025-04-01 13:08:58 +0200 | <kqr> | If I have a function returning a Maybe of something, and I want to return a Nothing, I can return `mempty` but I can also return `empty`. I have a rough intuition that `mempty` is more appropriate for things that are supposed to be aggregated together, whereas `empty` is more appropriate for things that are supposed to be used a choices. But how would I know which to use? |
| 2025-04-01 13:09:16 +0200 | <kqr> | I could, of course, also return a plain `Nothing` but in this case I want the function to be generic over both Maybe values and lists. |
| 2025-04-01 13:15:08 +0200 | tromp | (~textual@2001:1c00:3487:1b00:29bc:7fae:9d9f:d545) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2025-04-01 13:16:03 +0200 | <merijn> | kqr: If the type is fixed to be Maybe there is not distinction |
| 2025-04-01 13:16:18 +0200 | <merijn> | otoh, if the type is fixed to be Maybe, why not just write Nothing for readability |
| 2025-04-01 13:16:53 +0200 | <kqr> | This is in a module-private function that is called by two other exported functions, one of which specialise it to Maybe a, and the other to [a] |
| 2025-04-01 13:17:33 +0200 | <kqr> | I guess another way to phrase the question would be "When a result is interpreted either as a Maybe a or [a], is Monoid or Alternative the most intuitive generalisation?" |
| 2025-04-01 13:18:19 +0200 | <kqr> | Notably, this function only uses pure and empty, it never uses operators <|> or <> |
| 2025-04-01 13:18:34 +0200 | <Leary> | kqr: `mempty` would impose an unwanted `Semigroup` constraint. Also, I suspect you really want `guard`. |
| 2025-04-01 13:18:53 +0200 | xff0x | (~xff0x@2405:6580:b080:900:974d:9d72:56de:9211) |
| 2025-04-01 13:19:29 +0200 | <merijn> | Leary: You mean Monoid |
| 2025-04-01 13:19:40 +0200 | <merijn> | Semigroups (pretty notably) do not have mempty |
| 2025-04-01 13:19:48 +0200 | <merijn> | In fact, it's like, their main distinguishing feature :p |
| 2025-04-01 13:20:24 +0200 | <Leary> | Well, generalising, yeah. I was thinking about `instance Semigroup a => Monoid (Maybe a)`. |
| 2025-04-01 13:21:03 +0200 | toby-bro | (~toby-bro@user/toby-bro) toby-bro |
| 2025-04-01 13:24:37 +0200 | <Leary> | > let test = [guard False $> 'a', guard True $> 'a'] in (test :: [String], test :: [Maybe Char]) |
| 2025-04-01 13:24:39 +0200 | <lambdabot> | (["","a"],[Nothing,Just 'a']) |
| 2025-04-01 13:29:36 +0200 | <kqr> | I guess that is a vote in favour of Alternative? |
| 2025-04-01 13:31:12 +0200 | <Leary> | Indeed. |
| 2025-04-01 13:35:41 +0200 | tromp | (~textual@2001:1c00:3487:1b00:29bc:7fae:9d9f:d545) |
| 2025-04-01 13:41:09 +0200 | merijn | (~merijn@77.242.116.146) (Ping timeout: 248 seconds) |
| 2025-04-01 13:44:21 +0200 | merijn | (~merijn@77.242.116.146) merijn |
| 2025-04-01 13:45:58 +0200 | __monty__ | (~toonn@user/toonn) toonn |
| 2025-04-01 13:46:13 +0200 | tromp | (~textual@2001:1c00:3487:1b00:29bc:7fae:9d9f:d545) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2025-04-01 13:46:48 +0200 | fp | (~Thunderbi@2001:708:150:10::1d80) (Ping timeout: 272 seconds) |
| 2025-04-01 13:57:28 +0200 | tremon | (~tremon@83.80.159.219) tremon |
| 2025-04-01 14:00:51 +0200 | Smiles | (uid551636@id-551636.lymington.irccloud.com) Smiles |
| 2025-04-01 14:14:49 +0200 | <hellwolf> | This one I did not know. Why It is a "redundant bang pattern" using in line 4: https://paste.tomsmeding.com/1KVgpGax ? |
| 2025-04-01 14:15:22 +0200 | jespada | (~jespada@2800:a4:2256:6500:9933:8787:b375:7c3e) jespada |
| 2025-04-01 14:15:54 +0200 | <hellwolf> | > Bang patterns do not have any effect with constructor patterns: |
| 2025-04-01 14:15:56 +0200 | <lambdabot> | <hint>:1:64: error: |
| 2025-04-01 14:15:56 +0200 | <lambdabot> | parse error (possibly incorrect indentation or mismatched brackets) |
| 2025-04-01 14:16:02 +0200 | <hellwolf> | just read the doc. |
| 2025-04-01 14:16:41 +0200 | <hellwolf> | good to know. thanks hlint. |
| 2025-04-01 14:16:47 +0200 | <hellwolf> | makes sense. |
| 2025-04-01 14:17:00 +0200 | JuanDaugherty | (~juan@user/JuanDaugherty) JuanDaugherty |
| 2025-04-01 14:20:15 +0200 | srk | (~sorki@user/srk) (Ping timeout: 244 seconds) |
| 2025-04-01 14:21:30 +0200 | merijn | (~merijn@77.242.116.146) (Ping timeout: 246 seconds) |
| 2025-04-01 14:25:24 +0200 | Googulator18 | (~Googulato@178-164-243-34.pool.digikabel.hu) (Quit: Client closed) |
| 2025-04-01 14:25:42 +0200 | Googulator18 | (~Googulato@2a01-036d-0106-211a-ac5d-24c1-ad5e-7f2b.pool6.digikabel.hu) |
| 2025-04-01 14:33:27 +0200 | merijn | (~merijn@77.242.116.146) merijn |
| 2025-04-01 14:33:31 +0200 | srk | (~sorki@user/srk) srk |
| 2025-04-01 14:34:15 +0200 | <tomsmeding> | (in order to know that it is indeed that constructor, the runtime will have to evaluate it down to a constructor anyway. That's why it's strict.) |
| 2025-04-01 14:34:44 +0200 | <tomsmeding> | (This reasoning doesn't quite hold up for single-constructor data types, but for uniformity and "principle of least surprise" it makes much more sense to extend this principle to single-constructor data types too.) |
| 2025-04-01 14:36:52 +0200 | JuanDaugherty | (~juan@user/JuanDaugherty) (Quit: praxis.meansofproduction.biz (juan@acm.org)) |
| 2025-04-01 14:41:43 +0200 | jespada | (~jespada@2800:a4:2256:6500:9933:8787:b375:7c3e) (Quit: My Mac has gone to sleep. ZZZzzz…) |
| 2025-04-01 14:46:24 +0200 | zungi | (~tory@user/andrewchawk) (Ping timeout: 264 seconds) |
| 2025-04-01 14:50:55 +0200 | zungi | (~tory@user/andrewchawk) andrewchawk |
| 2025-04-01 14:51:27 +0200 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Quit: = "") |
| 2025-04-01 14:59:21 +0200 | <hellwolf> | is there optimization regarding single-constructor data type? |
| 2025-04-01 15:05:11 +0200 | Googulator18 | (~Googulato@2a01-036d-0106-211a-ac5d-24c1-ad5e-7f2b.pool6.digikabel.hu) (Quit: Client closed) |
| 2025-04-01 15:05:28 +0200 | Googulator18 | (~Googulato@2a01-036d-0106-211a-ac5d-24c1-ad5e-7f2b.pool6.digikabel.hu) |
| 2025-04-01 15:06:51 +0200 | comerijn | (~merijn@77.242.116.146) merijn |
| 2025-04-01 15:10:05 +0200 | merijn | (~merijn@77.242.116.146) (Ping timeout: 265 seconds) |
| 2025-04-01 15:13:38 +0200 | fp | (~Thunderbi@2001:708:150:10::1d80) fp |
| 2025-04-01 15:14:59 +0200 | tromp | (~textual@2001:1c00:3487:1b00:29bc:7fae:9d9f:d545) |
| 2025-04-01 15:22:22 +0200 | Digitteknohippie | (~user@user/digit) Digit |
| 2025-04-01 15:23:04 +0200 | Digit | (~user@user/digit) (Ping timeout: 272 seconds) |
| 2025-04-01 15:23:43 +0200 | CiaoSen | (~Jura@2a02:8071:64e1:da0:5a47:caff:fe78:33db) (Ping timeout: 245 seconds) |
| 2025-04-01 15:33:01 +0200 | notdabs | (~Owner@2600:1700:69cf:9000:553a:e935:8c4f:3651) |
| 2025-04-01 15:37:11 +0200 | Otong | (~Otong@user/Otong) Otong |
| 2025-04-01 15:37:40 +0200 | Otong | (~Otong@user/Otong) (Remote host closed the connection) |
| 2025-04-01 15:38:19 +0200 | Otong | (~Otong@user/Otong) Otong |
| 2025-04-01 15:38:28 +0200 | Otong | (~Otong@user/Otong) (Remote host closed the connection) |
| 2025-04-01 15:43:17 +0200 | acidjnk_new | (~acidjnk@p200300d6e71c4f8289e7d3d4c6144767.dip0.t-ipconnect.de) (Ping timeout: 248 seconds) |
| 2025-04-01 15:47:52 +0200 | fantom | (~fantom@2.219.56.221) (Ping timeout: 244 seconds) |
| 2025-04-01 15:48:24 +0200 | rit | (~rit@2409:40e0:101e:42e7:101c:ea47:4905:baf6) |
| 2025-04-01 15:48:24 +0200 | rit | (~rit@2409:40e0:101e:42e7:101c:ea47:4905:baf6) (Remote host closed the connection) |
| 2025-04-01 15:48:32 +0200 | rit | (~rit@2409:40e0:101e:42e7:101c:ea47:4905:baf6) |
| 2025-04-01 15:49:11 +0200 | Digitteknohippie | Digit |
| 2025-04-01 15:54:16 +0200 | fantom | (~fantom@2.219.56.221) |
| 2025-04-01 15:55:44 +0200 | <EvanR> | hellwolf, bang patterns are syntax sugar for seq |
| 2025-04-01 15:58:33 +0200 | <EvanR> | semantically at least |
| 2025-04-01 16:01:24 +0200 | Leary | (~Leary@user/Leary/x-0910699) (Ping timeout: 268 seconds) |
| 2025-04-01 16:02:57 +0200 | comerijn | (~merijn@77.242.116.146) (Ping timeout: 248 seconds) |
| 2025-04-01 16:03:40 +0200 | <EvanR> | a special case I found is let !x = e in body ==> let x = e in x `seq` body |
| 2025-04-01 16:04:23 +0200 | <EvanR> | so if x is a constructor pattern, the seq wouldn't have any effect |
| 2025-04-01 16:05:39 +0200 | <tomsmeding> | yes it would, a let is lazy |
| 2025-04-01 16:05:49 +0200 | <tomsmeding> | the bang-on-constructor-that-has-no-effect is in a pattern match |
| 2025-04-01 16:05:56 +0200 | ash3en | (~Thunderbi@149.222.150.125) (Ping timeout: 252 seconds) |
| 2025-04-01 16:06:18 +0200 | <hellwolf> | `let !(x1, x2) in _` is different than `let (!x1, !x2) in _`; it doesn't make intuitive sense, or does it to you? |
| 2025-04-01 16:07:51 +0200 | <tomsmeding> | it does; ! evaluates to WHNF |
| 2025-04-01 16:08:13 +0200 | merijn | (~merijn@77.242.116.146) merijn |
| 2025-04-01 16:08:16 +0200 | <tomsmeding> | the WHNF of a type is _just_ the outermost constructor, plus any strict fields of that constructor |
| 2025-04-01 16:08:36 +0200 | <tomsmeding> | the 2 fields of (,) are lazy, so evaluating a value of type (Int, Int) to WHNF just evaluates the outer (,) constructor, not the contained Ints |
| 2025-04-01 16:09:00 +0200 | <tomsmeding> | `(!x1, !x2)` evaluates the two fields explicitly, and thus also implicitly the constructor from which the two fields are projected |
| 2025-04-01 16:09:43 +0200 | Googulator18 | (~Googulato@2a01-036d-0106-211a-ac5d-24c1-ad5e-7f2b.pool6.digikabel.hu) (Quit: Client closed) |
| 2025-04-01 16:10:00 +0200 | Googulator18 | (~Googulato@2a01-036d-0106-211a-ac5d-24c1-ad5e-7f2b.pool6.digikabel.hu) |
| 2025-04-01 16:10:04 +0200 | <hellwolf> | if (!x1, !x2), should it not imply that the constructor has been also strictly evaluated? |
| 2025-04-01 16:10:17 +0200 | <tomsmeding> | yes |
| 2025-04-01 16:10:28 +0200 | <tomsmeding> | that's what I meant with "implicitly the constructor ..." |
| 2025-04-01 16:10:33 +0200 | <hellwolf> | but it's not. let me shend you an example. |
| 2025-04-01 16:10:53 +0200 | <hellwolf> | (i don't know why) |
| 2025-04-01 16:10:57 +0200 | <hellwolf> | btw re WHNF. need a sister thread for coming up with an enterprise naming for WHNF (reference: if you haven't seen the thread for having a "approachable name" of monad on X) |
| 2025-04-01 16:11:38 +0200 | <tomsmeding> | lax-face standard shape |
| 2025-04-01 16:13:17 +0200 | mari-estel | (~mari-este@user/mari-estel) mari-estel |
| 2025-04-01 16:17:11 +0200 | weary-traveler | (~user@user/user363627) user363627 |
| 2025-04-01 16:17:27 +0200 | <hellwolf> | I can't seem to recreate the scenario in a smaller example. to bad. |
| 2025-04-01 16:20:37 +0200 | acidjnk_new | (~acidjnk@p200300d6e71c4f8289e7d3d4c6144767.dip0.t-ipconnect.de) acidjnk |
| 2025-04-01 16:22:53 +0200 | <hellwolf> | oh, i got it. need 9.10. |
| 2025-04-01 16:24:11 +0200 | <hellwolf> | here you go: (x, y) = xy |
| 2025-04-01 16:24:21 +0200 | <hellwolf> | oops, code gone |
| 2025-04-01 16:24:48 +0200 | <hellwolf> | :( playground C-z fail. |
| 2025-04-01 16:24:57 +0200 | <hellwolf> | (I accidentally clicked Basic Template button. |
| 2025-04-01 16:28:04 +0200 | <tomsmeding> | :o |
| 2025-04-01 16:28:24 +0200 | <hellwolf> | https://play.haskell.org/saved/h4hw8OFx |
| 2025-04-01 16:28:29 +0200 | <hellwolf> | anyways, retyped. |
| 2025-04-01 16:28:47 +0200 | <tomsmeding> | oh this is linear haskell specific |
| 2025-04-01 16:29:32 +0200 | <tomsmeding> | I suspect this is more about specifically the multiplicity inference rules in LinearHaskell than about strictness |
| 2025-04-01 16:29:35 +0200 | Leary | (~Leary@user/Leary/x-0910699) Leary |
| 2025-04-01 16:30:39 +0200 | Digitteknohippie | (~user@user/digit) Digit |
| 2025-04-01 16:33:28 +0200 | Digit | (~user@user/digit) (Ping timeout: 268 seconds) |
| 2025-04-01 16:39:28 +0200 | <tomsmeding> | hellwolf: that C-z not working is a bug and I'll fix it, but how did you manage to type all that code before the button disappeared? |
| 2025-04-01 16:39:56 +0200 | <tomsmeding> | or does it not disappear for you? |
| 2025-04-01 16:40:38 +0200 | <hellwolf> | I typed then I wanted to share. |
| 2025-04-01 16:40:43 +0200 | <hellwolf> | but I clicked the wrong button :/ |
| 2025-04-01 16:41:22 +0200 | <tomsmeding> | the button is supposed to disappear after about 4 seconds after you interact with the page |
| 2025-04-01 16:41:31 +0200 | <tomsmeding> | the fact that it was stil there for you means that that didn't work |
| 2025-04-01 16:41:34 +0200 | <hellwolf> | it shows up all the time for me |
| 2025-04-01 16:41:51 +0200 | <hellwolf> | I think it responds to input event. |
| 2025-04-01 16:42:07 +0200 | <tomsmeding> | what browser are you using? |
| 2025-04-01 16:42:21 +0200 | <hellwolf> | firefox |
| 2025-04-01 16:42:49 +0200 | <tomsmeding> | me too |
| 2025-04-01 16:43:43 +0200 | <tomsmeding> | I'm attaching an event handler to the mousemove and keydown events, globally on the page |
| 2025-04-01 16:43:54 +0200 | <tomsmeding> | it would be very weird if those don't fire for you |
| 2025-04-01 16:44:05 +0200 | <tomsmeding> | any errors in the javascript console? |
| 2025-04-01 16:45:34 +0200 | gLLMguy | glguy |
| 2025-04-01 16:45:55 +0200 | <hellwolf> | no, I can't reproduce anymore |
| 2025-04-01 16:46:00 +0200 | <hellwolf> | with a new tab |
| 2025-04-01 16:46:08 +0200 | <tomsmeding> | the button disappears now for you? |
| 2025-04-01 16:46:15 +0200 | <hellwolf> | in the new tab. yes. |
| 2025-04-01 16:46:19 +0200 | <tomsmeding> | O.o |
| 2025-04-01 16:47:18 +0200 | rit | (~rit@2409:40e0:101e:42e7:101c:ea47:4905:baf6) (Ping timeout: 240 seconds) |
| 2025-04-01 16:47:22 +0200 | longlongdouble | (~longlongd@2405:201:5c16:894:2d75:fd2d:c031:9b09) |
| 2025-04-01 16:47:27 +0200 | longlongdouble | (~longlongd@2405:201:5c16:894:2d75:fd2d:c031:9b09) (Client Quit) |
| 2025-04-01 16:50:38 +0200 | <EvanR> | tomsmeding, well that translation I gave is in the docs let !x = e in body ==> let x = e in x `seq` body. You're saying let !K = e in body is somehow different from let K = e in K `seq` body? |
| 2025-04-01 16:50:52 +0200 | <EvanR> | or maybe it was only talking about variable bindings |
| 2025-04-01 16:51:04 +0200 | <EvanR> | lol what does `x' quantify over |
| 2025-04-01 16:51:08 +0200 | <tomsmeding> | EvanR: no, I was complaining about your claim that the seq doesn't have any effect if x is a constructor pattern |
| 2025-04-01 16:51:22 +0200 | jmcantrell | (~weechat@user/jmcantrell) jmcantrell |
| 2025-04-01 16:51:25 +0200 | <tomsmeding> | it does _here_, but not in a pattern match, because pattern matches are strict and let is lazy |
| 2025-04-01 16:51:45 +0200 | <EvanR> | let K = ... is a pattern match or a let |
| 2025-04-01 16:51:50 +0200 | <EvanR> | or both |
| 2025-04-01 16:52:01 +0200 | <tomsmeding> | a let |
| 2025-04-01 16:52:09 +0200 | <tomsmeding> | okay "pattern match" is indeed ambiguous wording |
| 2025-04-01 16:52:21 +0200 | <EvanR> | I have no idea what you're saying xD |
| 2025-04-01 16:52:50 +0200 | <tomsmeding> | `case x of K -> _` is strict in x |
| 2025-04-01 16:52:56 +0200 | Digitteknohippie | Digit |
| 2025-04-01 16:53:02 +0200 | <tomsmeding> | the function `foo K = _` is strict in its argument |
| 2025-04-01 16:53:25 +0200 | <tomsmeding> | `let K = expr in _` is _not_ strict in `expr` |
| 2025-04-01 16:53:54 +0200 | <tomsmeding> | I used "pattern match" to refer to the first two, but that's ambiguous, I concede |
| 2025-04-01 16:54:12 +0200 | gmg | (~user@user/gehmehgeh) (Ping timeout: 264 seconds) |
| 2025-04-01 16:54:15 +0200 | <tomsmeding> | `let !K = expr in _` is, however, strict in `expr` |
| 2025-04-01 16:54:20 +0200 | gehmehgeh | (~user@user/gehmehgeh) gehmehgeh |
| 2025-04-01 16:54:48 +0200 | mari-estel | (~mari-este@user/mari-estel) (Remote host closed the connection) |
| 2025-04-01 16:56:21 +0200 | <EvanR> | alright I think my substitution failed |
| 2025-04-01 16:56:57 +0200 | <tomsmeding> | hellwolf: https://github.com/haskell/play-haskell/commit/5630aaa0da9fb7ffaecf43fc526a8ff5024b5d84 the undo problem should be fixed now, in case you manage to be super fast anyway or if the button remains for whatever reason |
| 2025-04-01 16:57:04 +0200 | <EvanR> | let !K = e in body isn't an instance of the rule let !x = e in body, when you translate them you get different behaving results |
| 2025-04-01 16:57:28 +0200 | <EvanR> | x is supposed to range over variables, not any pattern xD |
| 2025-04-01 16:57:33 +0200 | <EvanR> | metavariable |
| 2025-04-01 16:57:46 +0200 | <hellwolf> | tomsmeding: great! |
| 2025-04-01 16:58:22 +0200 | <tomsmeding> | I don't know why ace.js thought it was a good idea to explicitly clear undo history when setting the contents of an edit session to a new srting |
| 2025-04-01 17:01:04 +0200 | ubert | (~Thunderbi@2a02:8109:ab8a:5a00:74f1:1caf:2629:a3c8) ubert |
| 2025-04-01 17:01:25 +0200 | <hellwolf> | frontend is voodoo to me... sounds like you can use some monad |
| 2025-04-01 17:04:36 +0200 | acidjnk_new | (~acidjnk@p200300d6e71c4f8289e7d3d4c6144767.dip0.t-ipconnect.de) (Ping timeout: 246 seconds) |
| 2025-04-01 17:04:41 +0200 | <EvanR> | some kinda monad or smth |
| 2025-04-01 17:06:11 +0200 | kawzeg | (kawzeg@2a01:7e01::f03c:92ff:fee2:ec34) kawzeg |
| 2025-04-01 17:17:42 +0200 | acidjnk_new | (~acidjnk@p200300d6e71c4f82640579a6e00084b6.dip0.t-ipconnect.de) acidjnk |
| 2025-04-01 17:19:12 +0200 | tzh | (~tzh@c-76-115-131-146.hsd1.or.comcast.net) tzh |
| 2025-04-01 17:23:25 +0200 | <EvanR> | so let !(x,y) = e in body is substantially different from let (x,y) = e in body, because e gets evaluated earlier. Right? |
| 2025-04-01 17:23:45 +0200 | <EvanR> | but in case alternatives it has no effect |
| 2025-04-01 17:24:15 +0200 | <tomsmeding> | in `let (x,y) = e in body`, e might not get evaluated at all if x and y are unused |
| 2025-04-01 17:24:37 +0200 | <tomsmeding> | indeed, `case _ of !(x,y) -> _` is equivalent to `case _ of (x,y) -> _` |
| 2025-04-01 17:25:09 +0200 | werneta | (~werneta@syn-071-083-160-242.res.spectrum.com) (Ping timeout: 248 seconds) |
| 2025-04-01 17:25:53 +0200 | <merijn> | I'm not sure you can ever observe the difference between those two, EvanR |
| 2025-04-01 17:26:09 +0200 | <EvanR> | ???? |
| 2025-04-01 17:26:33 +0200 | <EvanR> | > let !(x,y) = undefined in "ok" |
| 2025-04-01 17:26:35 +0200 | <lambdabot> | "*Exception: Prelude.undefined |
| 2025-04-01 17:26:40 +0200 | <EvanR> | > let (x,y) = undefined in "ok" |
| 2025-04-01 17:26:42 +0200 | <lambdabot> | "ok" |
| 2025-04-01 17:26:52 +0200 | <merijn> | As in, if you don't use either x or y is there a chance it gets optimised away |
| 2025-04-01 17:26:55 +0200 | <merijn> | I'm not sure |
| 2025-04-01 17:27:05 +0200 | <tomsmeding> | merijn: uh, bang patterns have semantics :p |
| 2025-04-01 17:27:12 +0200 | <tomsmeding> | it's not optimiser vagaries |
| 2025-04-01 17:27:46 +0200 | <EvanR> | unfortunately, the rule I just posted doesn't apply to this specific let, you need one of the other semantic rules... and there's a lot apparently for bang patterns |
| 2025-04-01 17:27:47 +0200 | <merijn> | tomsmeding: I meant that if the entire binding is unused does GHC keep it just for forcing the evaluation? |
| 2025-04-01 17:27:53 +0200 | <tomsmeding> | yes |
| 2025-04-01 17:28:03 +0200 | <tomsmeding> | otherwise what would the bang pattern even mean |
| 2025-04-01 17:28:08 +0200 | <merijn> | I need to rereads the documentation on bangpatterns |
| 2025-04-01 17:28:40 +0200 | <EvanR> | crashing or freezing due to bottom might be an intended observable effect |
| 2025-04-01 17:28:47 +0200 | <EvanR> | i.e. using lub |
| 2025-04-01 17:28:51 +0200 | <tomsmeding> | precisely |
| 2025-04-01 17:30:08 +0200 | <tomsmeding> | ah, the GHC docs for BangPatterns point out that `let !x` is not the same as `let (!x)` |
| 2025-04-01 17:30:17 +0200 | <EvanR> | o_O |
| 2025-04-01 17:30:29 +0200 | <int-e> | > let a = let !(x,y) = a in (0,x) in a |
| 2025-04-01 17:30:30 +0200 | <tomsmeding> | or wait |
| 2025-04-01 17:30:32 +0200 | <lambdabot> | *Exception: <<loop>> |
| 2025-04-01 17:30:36 +0200 | <int-e> | > let a = let (x,y) = a in (0,x) in a |
| 2025-04-01 17:30:38 +0200 | <lambdabot> | (0,0) |
| 2025-04-01 17:31:00 +0200 | <int-e> | > let a = let (!(x,y)) = a in (0,x) in a |
| 2025-04-01 17:31:02 +0200 | <lambdabot> | *Exception: <<loop>> |
| 2025-04-01 17:31:12 +0200 | <tomsmeding> | ah no, there is a semantical difference between a top-level bang pattern in a let binding, and a bang somewhere nested |
| 2025-04-01 17:31:16 +0200 | <EvanR> | that would be an interesting thing to optimize out |
| 2025-04-01 17:31:26 +0200 | <tomsmeding> | but "top-level" may be under parentheses |
| 2025-04-01 17:31:34 +0200 | <int-e> | but (!x) is still top-level, |
| 2025-04-01 17:31:34 +0200 | <tomsmeding> | I'm half-sure this changed at some point |
| 2025-04-01 17:31:42 +0200 | <int-e> | as you said (failed to delete) |
| 2025-04-01 17:31:56 +0200 | <EvanR> | the one I was reading said strict bindings are not allowed at top level but I guess that's old now? |
| 2025-04-01 17:32:11 +0200 | <tomsmeding> | what are you reading? |
| 2025-04-01 17:32:21 +0200 | tromp | (~textual@2001:1c00:3487:1b00:29bc:7fae:9d9f:d545) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2025-04-01 17:32:53 +0200 | <EvanR> | >Strict bindings are not allowed at the top level of a module. |
| 2025-04-01 17:33:00 +0200 | <EvanR> | https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/strict.html |
| 2025-04-01 17:33:01 +0200 | <tomsmeding> | ah, that's top-level in a module |
| 2025-04-01 17:33:05 +0200 | <int-e> | @let !x = () |
| 2025-04-01 17:33:05 +0200 | <tomsmeding> | I mean top-level in a pattern |
| 2025-04-01 17:33:06 +0200 | <lambdabot> | /sandbox/tmp/.L.hs:168:1: error: |
| 2025-04-01 17:33:06 +0200 | <lambdabot> | Top-level strict bindings aren't allowed: !L.x = () |
| 2025-04-01 17:33:06 +0200 | <lambdabot> | | |
| 2025-04-01 17:33:18 +0200 | Googulator18 | (~Googulato@2a01-036d-0106-211a-ac5d-24c1-ad5e-7f2b.pool6.digikabel.hu) (Quit: Client closed) |
| 2025-04-01 17:33:20 +0200 | <EvanR> | what's top level in a pattern |
| 2025-04-01 17:33:24 +0200 | rvalue | (~rvalue@user/rvalue) (Read error: Connection reset by peer) |
| 2025-04-01 17:33:24 +0200 | <tomsmeding> | where `let !(x,y)` would be a "top-level" bang pattern, and `let (!x,y)` would not be |
| 2025-04-01 17:33:44 +0200 | Googulator18 | (~Googulato@2a01-036d-0106-211a-ac5d-24c1-ad5e-7f2b.pool6.digikabel.hu) |
| 2025-04-01 17:33:49 +0200 | <EvanR> | so wtf is let (!x) = ... |
| 2025-04-01 17:33:55 +0200 | rvalue | (~rvalue@user/rvalue) rvalue |
| 2025-04-01 17:34:00 +0200 | <tomsmeding> | ambiguous |
| 2025-04-01 17:34:00 +0200 | <int-e> | EvanR: it's equivalent to let !x = ... |
| 2025-04-01 17:34:04 +0200 | <EvanR> | lol |
| 2025-04-01 17:34:06 +0200 | <tomsmeding> | yes, that's how ghc interprets it |
| 2025-04-01 17:34:15 +0200 | <EvanR> | ok so we're not lisp yet |
| 2025-04-01 17:34:15 +0200 | <int-e> | (empirically) |
| 2025-04-01 17:34:39 +0200 | <tomsmeding> | > let (x,!y) = ("x", undefined) in "hi " ++ x |
| 2025-04-01 17:34:41 +0200 | <lambdabot> | "hi *Exception: Prelude.undefined |
| 2025-04-01 17:34:45 +0200 | <tomsmeding> | > let (x,!y) = ("x", undefined) in "hi" |
| 2025-04-01 17:34:47 +0200 | <lambdabot> | "hi" |
| 2025-04-01 17:34:51 +0200 | <int-e> | but for a newtype T, !(T x) and T (!x) should be different |
| 2025-04-01 17:35:00 +0200 | <tomsmeding> | non-top-level bang patterns only have an effect if the pattern as a whole is used |
| 2025-04-01 17:35:07 +0200 | <tomsmeding> | in a let, that is |
| 2025-04-01 17:35:32 +0200 | <tomsmeding> | top-level bang patterns have the additional effect of making the whole binding strict |
| 2025-04-01 17:35:57 +0200 | <tomsmeding> | int-e: should they? |
| 2025-04-01 17:36:11 +0200 | <int-e> | tomsmeding: yes, and they are different too |
| 2025-04-01 17:36:27 +0200 | <int-e> | those top-level ! override an implicit outermost ~ |
| 2025-04-01 17:36:32 +0200 | mari-estel | (~mari-este@user/mari-estel) mari-estel |
| 2025-04-01 17:36:55 +0200 | <EvanR> | what implicit outermost ~ |
| 2025-04-01 17:37:01 +0200 | <tomsmeding> | oh right, exactly because of what I just said |
| 2025-04-01 17:37:17 +0200 | <EvanR> | or we're just talking about let bindings |
| 2025-04-01 17:37:20 +0200 | <EvanR> | still |
| 2025-04-01 17:37:20 +0200 | <int-e> | a non-recursive let x = foo in ... is more or less case foo of ~x -> ... |
| 2025-04-01 17:37:47 +0200 | <tomsmeding> | if T is a newtype then `case _ of T (!x) -> _` is the same as `case _ of !(T x) -> _` is the same as `case _ of T x -> _` because there is no distinct `T _|_` thunk |
| 2025-04-01 17:37:48 +0200 | <EvanR> | how is that different from case foo of x -> |
| 2025-04-01 17:38:05 +0200 | <tomsmeding> | with let bindings, an outermost ! specifically has additional semantics of making the binding strict instead of lazy |
| 2025-04-01 17:38:08 +0200 | <EvanR> | because foo is evaluated |
| 2025-04-01 17:38:10 +0200 | <int-e> | EvanR: ah my `x` is a placeholder for a pattern |
| 2025-04-01 17:38:11 +0200 | <int-e> | sorry |
| 2025-04-01 17:38:14 +0200 | <EvanR> | lol |
| 2025-04-01 17:38:26 +0200 | <EvanR> | earlier x was a placeholder for any variable |
| 2025-04-01 17:38:27 +0200 | <tomsmeding> | > let Identity x = undefined in () |
| 2025-04-01 17:38:29 +0200 | <lambdabot> | () |
| 2025-04-01 17:38:30 +0200 | <EvanR> | now it's any pattern |
| 2025-04-01 17:38:33 +0200 | <tomsmeding> | > let !(Identity x) = undefined in () |
| 2025-04-01 17:38:34 +0200 | <lambdabot> | *Exception: Prelude.undefined |
| 2025-04-01 17:38:38 +0200 | <tomsmeding> | > let Identity !x = undefined in () |
| 2025-04-01 17:38:40 +0200 | <lambdabot> | () |
| 2025-04-01 17:38:46 +0200 | <tomsmeding> | > let Identity (!x) = undefined in () |
| 2025-04-01 17:38:47 +0200 | <lambdabot> | () |
| 2025-04-01 17:39:04 +0200 | <int-e> | tomsmeding: right, but for `let` they behave differently: https://paste.tomsmeding.com/sQ0J5fNj |
| 2025-04-01 17:39:12 +0200 | <tomsmeding> | (see above) |
| 2025-04-01 17:39:47 +0200 | <tomsmeding> | the behaviour _is_ consistent with the docs, but it's a bit subtle |
| 2025-04-01 17:39:54 +0200 | CiaoSen | (~Jura@2a02:8071:64e1:da0:5a47:caff:fe78:33db) CiaoSen |
| 2025-04-01 17:40:07 +0200 | <int-e> | because T (!(x,y)) is treated like to ~(T (!(x,y))) |
| 2025-04-01 17:40:15 +0200 | <tomsmeding> | I guess |
| 2025-04-01 17:40:42 +0200 | <tomsmeding> | talking about an implicit ~ means that you're implicitly (!) assuming that patterns are strict by default |
| 2025-04-01 17:41:26 +0200 | <int-e> | > let !x = undefined in 42 |
| 2025-04-01 17:41:27 +0200 | <lambdabot> | *Exception: Prelude.undefined |
| 2025-04-01 17:41:29 +0200 | <tomsmeding> | I guess this particular point cannot be proved nor disproved, though, because the spec is just that they behave the way they do |
| 2025-04-01 17:41:54 +0200 | <int-e> | EvanR: re: "What is !x" -- it's different from an unadorned x when it's a variable pattern. |
| 2025-04-01 17:42:32 +0200 | fp | (~Thunderbi@2001:708:150:10::1d80) (Ping timeout: 268 seconds) |
| 2025-04-01 17:43:31 +0200 | <int-e> | tomsmeding: Yes, to me the more fundamental semantics of patterns are the ones that match what `case` does. So ... matching constructors is strict; variable patterns are not. |
| 2025-04-01 17:43:48 +0200 | <int-e> | `let` tweaks this at the outermost level. |
| 2025-04-01 17:44:05 +0200 | XZDX | (~xzdx@c-68-55-21-207.hsd1.mi.comcast.net) (Remote host closed the connection) |
| 2025-04-01 17:44:24 +0200 | <tomsmeding> | right |
| 2025-04-01 17:44:35 +0200 | <tomsmeding> | I guess that makes sense |
| 2025-04-01 17:45:26 +0200 | <hellwolf> | λ [d| f x = let !(x1) =x in x1 |] |
| 2025-04-01 17:45:26 +0200 | <hellwolf> | [FunD f_0 [Clause [VarP x_1] (NormalB (LetE [ValD (BangP (VarP x1_2)) (NormalB (VarE x_1)) []] (VarE x1_2))) []]] |
| 2025-04-01 17:45:40 +0200 | <hellwolf> | template haskell would generate the same thing whereever you put the Bang |
| 2025-04-01 17:46:02 +0200 | <hellwolf> | Does it prove anything? |
| 2025-04-01 17:46:02 +0200 | <EvanR> | it's template haskell official |
| 2025-04-01 17:47:06 +0200 | <EvanR> | what is NormalB referring to |
| 2025-04-01 17:47:21 +0200 | <tomsmeding> | a normal body, without guards |
| 2025-04-01 17:47:38 +0200 | <tomsmeding> | % :set -XTemplateHaskell |
| 2025-04-01 17:47:38 +0200 | <yahb2> | <no output> |
| 2025-04-01 17:47:51 +0200 | <tomsmeding> | % [| let !x = undefined in () |] |
| 2025-04-01 17:47:51 +0200 | <yahb2> | LetE [ValD (BangP (VarP x_0)) (NormalB (VarE GHC.Internal.Err.undefined)) []] (ConE GHC.Tuple.()) |
| 2025-04-01 17:48:01 +0200 | <tomsmeding> | % [| let !x = x in x |] |
| 2025-04-01 17:48:01 +0200 | <yahb2> | LetE [ValD (BangP (VarP x_1)) (NormalB (VarE x_1)) []] (VarE x_1) |
| 2025-04-01 17:48:03 +0200 | <tomsmeding> | huh |
| 2025-04-01 17:48:22 +0200 | <tomsmeding> | lol this is broken in 9.4? |
| 2025-04-01 17:48:35 +0200 | <tomsmeding> | locally on 9.4.7 I get: |
| 2025-04-01 17:48:36 +0200 | <int-e> | % [| let x | odd 1 = 42 in x |] |
| 2025-04-01 17:48:36 +0200 | <yahb2> | LetE [ValD (VarP x_2) (GuardedB [(NormalG (AppE (VarE GHC.Internal.Real.odd) (LitE (IntegerL 1))),LitE (IntegerL 42))]) []] (VarE x_2) |
| 2025-04-01 17:48:41 +0200 | <tomsmeding> | Prelude> [| let !x = x in x1 |] |
| 2025-04-01 17:48:43 +0200 | <tomsmeding> | LetE [ValD (VarP x_0) (NormalB (VarE x_0)) []] (UnboundVarE x1) |
| 2025-04-01 17:49:23 +0200 | <hellwolf> | nice, new way of flooding this channel. |
| 2025-04-01 17:49:52 +0200 | <int-e> | eh I don't think it's new |
| 2025-04-01 17:49:58 +0200 | <tomsmeding> | you mean yahb2? |
| 2025-04-01 17:50:39 +0200 | <hellwolf> | % [| _ |] |
| 2025-04-01 17:50:39 +0200 | <yahb2> | UnboundVarE _ |
| 2025-04-01 17:50:55 +0200 | <int-e> | % [| let !x = x in x1 |] |
| 2025-04-01 17:50:55 +0200 | <yahb2> | LetE [ValD (BangP (VarP x_3)) (NormalB (VarE x_3)) []] (UnboundVarE x1) |
| 2025-04-01 17:50:55 +0200 | <tomsmeding> | there was a yahb ("yet another haskell bot") before in the freenode era, run by... I think mauke? yahb2 is... yet another one |
| 2025-04-01 17:51:10 +0200 | <int-e> | tomsmeding: you had different inputs |
| 2025-04-01 17:51:18 +0200 | segfaultfizzbuzz | (~segfaultf@23-93-74-222.fiber.dynamic.sonic.net) segfaultfizzbuzz |
| 2025-04-01 17:51:31 +0200 | <tomsmeding> | int-e: note that yahb2 here added a BangP, as it should |
| 2025-04-01 17:51:43 +0200 | <tomsmeding> | if you try that on 9.4, you don't get a BangP |
| 2025-04-01 17:51:52 +0200 | <tomsmeding> | (yahb2 is on 9.12) |
| 2025-04-01 17:52:00 +0200 | <int-e> | tomsmeding: Oh. Fascinating. |
| 2025-04-01 17:52:29 +0200 | <hellwolf> | maybe it is a bot issue? |
| 2025-04-01 17:52:40 +0200 | <tomsmeding> | no, 9.4 has slightly broken TH parsing, apparently |
| 2025-04-01 17:52:47 +0200 | tromp | (~textual@2001:1c00:3487:1b00:29bc:7fae:9d9f:d545) |
| 2025-04-01 17:53:09 +0200 | <tomsmeding> | bug still occurs in 9.6, seems fixed in 9.8 |
| 2025-04-01 17:54:32 +0200 | mari-estel | (~mari-este@user/mari-estel) (Remote host closed the connection) |
| 2025-04-01 17:54:33 +0200 | tomsmeding | . o O ( no, the original yahb was run by mni'ip (without the '; wanted to avoid a ping) ) |
| 2025-04-01 17:56:01 +0200 | Smiles | (uid551636@id-551636.lymington.irccloud.com) (Quit: Connection closed for inactivity) |
| 2025-04-01 17:56:10 +0200 | <int-e> | . o O ( worst error message: '<command line>: Package environment "-" (specified in GHC_ENVIRIONMENT) not found' ) |
| 2025-04-01 17:56:23 +0200 | <tomsmeding> | how did you manage that |
| 2025-04-01 17:56:48 +0200 | <tomsmeding> | and is that typo in the env var name already in the message, or in your copying of it |
| 2025-04-01 17:56:58 +0200 | <int-e> | tomsmeding: That's GHC 8.0.2; I'm setting GHC_ENVIRONMENT for later versions. |
| 2025-04-01 17:57:46 +0200 | <int-e> | The terrible thing is that there's a typo in the environment variable name so you can't copy&paste it into an `unset` command |
| 2025-04-01 17:57:46 +0200 | <tomsmeding> | (what are you using 8.0 for) |
| 2025-04-01 17:57:53 +0200 | <tomsmeding> | right |
| 2025-04-01 17:58:03 +0200 | <tomsmeding> | chef's kiss |
| 2025-04-01 17:58:07 +0200 | CiaoSen | (~Jura@2a02:8071:64e1:da0:5a47:caff:fe78:33db) (Ping timeout: 252 seconds) |
| 2025-04-01 17:59:34 +0200 | <hellwolf> | I remember SPJ said once that GHC deleted files at some point. Talking about better type system for managing side effects. |
| 2025-04-01 18:00:18 +0200 | <hellwolf> | https://www.reddit.com/r/haskell/comments/kmk6q/the_best_ghc_bug_ever/ |
| 2025-04-01 18:00:30 +0200 | <tomsmeding> | int-e: the thing about parentheses being relevant was just a brainfart; I think I completely misremembered this: https://gitlab.haskell.org/ghc/ghc/-/issues/22057 |
| 2025-04-01 18:01:42 +0200 | <int-e> | tomsmeding: I was doing this experiment: https://paste.tomsmeding.com/Vbpiah8r |
| 2025-04-01 18:01:59 +0200 | <tomsmeding> | oh wow |
| 2025-04-01 18:02:12 +0200 | <tomsmeding> | _wat_ |
| 2025-04-01 18:02:20 +0200 | <int-e> | So this was broken for a fairly long time. |
| 2025-04-01 18:02:21 +0200 | <tomsmeding> | it broke again in 9.12? |
| 2025-04-01 18:02:58 +0200 | <int-e> | evidently? |
| 2025-04-01 18:03:15 +0200 | <tomsmeding> | I get a BangP both with 9.12.1 and 9.12.2 |
| 2025-04-01 18:03:36 +0200 | <int-e> | oh that's my bad |
| 2025-04-01 18:04:09 +0200 | <int-e> | I don't actually have 9.12.2 built, /opt/ghc-9.12.2 is empty |
| 2025-04-01 18:04:16 +0200 | <tomsmeding> | what did it do :p |
| 2025-04-01 18:04:19 +0200 | <int-e> | so it fell back on 9.6.6 |
| 2025-04-01 18:04:22 +0200 | <tomsmeding> | ah |
| 2025-04-01 18:04:30 +0200 | <int-e> | good catch, thanks |
| 2025-04-01 18:04:55 +0200 | <hellwolf> | I had a minor bug, I used bang pattern in a TH quote, and GHC complaining that I have unused variable, but I clearly used it. |
| 2025-04-01 18:04:55 +0200 | <hellwolf> | Considering the number of GHC issues, I don't think I should report and create one more issue there, for now. |
| 2025-04-01 18:05:22 +0200 | <int-e> | the other versions do exist :) |
| 2025-04-01 18:05:25 +0200 | <tomsmeding> | what is the case? Is it reasonable for GHC to detect it? |
| 2025-04-01 18:05:53 +0200 | <tomsmeding> | in general, if there's an issue in GHC, do report it; that's what the issue tracker is for |
| 2025-04-01 18:05:57 +0200 | <hellwolf> | here: https://paste.tomsmeding.com/JU7QBp5w |
| 2025-04-01 18:06:19 +0200 | <tomsmeding> | which variable do you get a warning about? |
| 2025-04-01 18:06:36 +0200 | <hellwolf> | let me find the error message, one sec |
| 2025-04-01 18:06:48 +0200 | tomsmeding | suspects mx1_ |
| 2025-04-01 18:07:08 +0200 | <hellwolf> | https://paste.tomsmeding.com/wRfhejVB |
| 2025-04-01 18:07:17 +0200 | <hellwolf> | mxs_ & mxs_' |
| 2025-04-01 18:08:04 +0200 | <tomsmeding> | this actually sounds extemely related to https://gitlab.haskell.org/ghc/ghc/-/issues/22057 |
| 2025-04-01 18:08:44 +0200 | <hellwolf> | I see, indeed. I might as well report one more sample to the same issue. |
| 2025-04-01 18:08:56 +0200 | <tomsmeding> | the fix for that PR is in 9.6; what GHC version are you using? |
| 2025-04-01 18:09:00 +0200 | <hellwolf> | 9.10 |
| 2025-04-01 18:09:36 +0200 | <tomsmeding> | you can indeed reply to the same issue; it's likely that you'll subsequently be instructed to create a new issue instead |
| 2025-04-01 18:09:52 +0200 | <hellwolf> | right. i didn't realize it was closed and fixed. |
| 2025-04-01 18:10:41 +0200 | tomsmeding | is afk for a while |
| 2025-04-01 18:11:51 +0200 | haskellbridge | (~hackager@syn-024-093-192-219.res.spectrum.com) (Remote host closed the connection) |
| 2025-04-01 18:12:02 +0200 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) peterbecich |
| 2025-04-01 18:14:48 +0200 | haskellbridge | (~hackager@syn-024-093-192-219.res.spectrum.com) hackager |
| 2025-04-01 18:14:48 +0200 | ChanServ | +v haskellbridge |
| 2025-04-01 18:15:32 +0200 | danza | (~danza@user/danza) danza |
| 2025-04-01 18:19:59 +0200 | merijn | (~merijn@77.242.116.146) (Ping timeout: 244 seconds) |
| 2025-04-01 18:20:33 +0200 | machinedgod | (~machinedg@d108-173-18-100.abhsia.telus.net) (Ping timeout: 248 seconds) |
| 2025-04-01 18:24:53 +0200 | aman | (~aman@user/aman) (Ping timeout: 252 seconds) |