2025/04/01

2025-04-01 00:01:54 +0200dhil(~dhil@2a0c:b381:52e:3600:1143:d61d:a64d:dc67) (Ping timeout: 246 seconds)
2025-04-01 00:02:30 +0200ljdarj1(~Thunderbi@user/ljdarj) ljdarj
2025-04-01 00:02:37 +0200weary-traveler(~user@user/user363627) user363627
2025-04-01 00:02:52 +0200L29Ah(~L29Ah@wikipedia/L29Ah) L29Ah
2025-04-01 00:06:11 +0200ljdarj(~Thunderbi@user/ljdarj) (Ping timeout: 268 seconds)
2025-04-01 00:06:11 +0200ljdarj1ljdarj
2025-04-01 00:08:43 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-04-01 00:13:42 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds)
2025-04-01 00:20:31 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-04-01 00:20:54 +0200manny69(~manny@2601:445:700:69b0:edc8:140b:9839:8c7d) (Ping timeout: 240 seconds)
2025-04-01 00:23:15 +0200tromp(~textual@2001:1c00:3487:1b00:29bc:7fae:9d9f:d545) (Quit: My iMac has gone to sleep. ZZZzzz…)
2025-04-01 00:25:26 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds)
2025-04-01 00:26:13 +0200remexre(~remexre@user/remexre) (Ping timeout: 245 seconds)
2025-04-01 00:27:10 +0200Eoco(~ian@128.101.131.218) (Ping timeout: 244 seconds)
2025-04-01 00:27:17 +0200jespada(~jespada@2800:a4:2231:f700:8971:aafc:a22d:7172) (Quit: My Mac has gone to sleep. ZZZzzz…)
2025-04-01 00:34:00 +0200Smiles(uid551636@id-551636.lymington.irccloud.com) Smiles
2025-04-01 00:34:47 +0200Eoco(~ian@128.101.131.218) Eoco
2025-04-01 00:36:20 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-04-01 00:36:46 +0200remexre(~remexre@user/remexre) remexre
2025-04-01 00:38:48 +0200peterbecich(~Thunderbi@syn-047-229-123-186.res.spectrum.com) peterbecich
2025-04-01 00:40:49 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 244 seconds)
2025-04-01 00:52:03 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-04-01 00:54:14 +0200Sgeo(~Sgeo@user/sgeo) Sgeo
2025-04-01 00:57:00 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 265 seconds)
2025-04-01 01:02:00 +0200ljdarj(~Thunderbi@user/ljdarj) (Ping timeout: 244 seconds)
2025-04-01 01:07:49 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-04-01 01:09:29 +0200toby-bro(~toby-bro@user/toby-bro) (Ping timeout: 260 seconds)
2025-04-01 01:12:44 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds)
2025-04-01 01:21:33 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-04-01 01:25:02 +0200cptaffe(~cptaffe@user/cptaffe) (Ping timeout: 265 seconds)
2025-04-01 01:27:50 +0200ft(~ft@p508db463.dip0.t-ipconnect.de) (Quit: Lost terminal)
2025-04-01 01:28:18 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 245 seconds)
2025-04-01 01:30:56 +0200peterbecich(~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 244 seconds)
2025-04-01 01:37:45 +0200xff0x(~xff0x@2405:6580:b080:900:1654:70d2:c294:d90) (Quit: xff0x)
2025-04-01 01:38:31 +0200sprotte24(~sprotte24@p200300d16f24f500b1cefbd2da3b16f9.dip0.t-ipconnect.de) (Quit: Leaving)
2025-04-01 01:38:59 +0200sprotte24(~sprotte24@p200300d16f24f500b1cefbd2da3b16f9.dip0.t-ipconnect.de)
2025-04-01 01:39:24 +0200sprotte24(~sprotte24@p200300d16f24f500b1cefbd2da3b16f9.dip0.t-ipconnect.de) (Client Quit)
2025-04-01 01:39:36 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-04-01 01:40:30 +0200Pixi`(~Pixi@user/pixi) Pixi
2025-04-01 01:40:39 +0200Tuplanolla(~Tuplanoll@91-159-69-59.elisa-laajakaista.fi) (Quit: Leaving.)
2025-04-01 01:42:18 +0200ft(~ft@p508db463.dip0.t-ipconnect.de) ft
2025-04-01 01:42:26 +0200forell(~forell@user/forell) (Ping timeout: 265 seconds)
2025-04-01 01:43:38 +0200Pixi(~Pixi@user/pixi) (Ping timeout: 244 seconds)
2025-04-01 01:43:53 +0200acidjnk_new(~acidjnk@p200300d6e71c4f027cb63b5a22c835f3.dip0.t-ipconnect.de) acidjnk
2025-04-01 01:44:37 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds)
2025-04-01 01:47:03 +0200acidjnk(~acidjnk@p200300d6e71c4f0205a1013c182d2742.dip0.t-ipconnect.de) (Ping timeout: 245 seconds)
2025-04-01 01:49:09 +0200acidjnk_new(~acidjnk@p200300d6e71c4f027cb63b5a22c835f3.dip0.t-ipconnect.de) (Ping timeout: 248 seconds)
2025-04-01 01:52:43 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-04-01 01:57:09 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 248 seconds)
2025-04-01 01:57:54 +0200xff0x(~xff0x@ai066236.d.east.v6connect.net)
2025-04-01 02:00:23 +0200abrar(~abrar@static-96-245-187-163.phlapa.fios.verizon.net) (Quit: WeeChat 4.4.3)
2025-04-01 02:00:55 +0200unter-oe(~unter-oe@user/unter-oe) unter-oe
2025-04-01 02:02:14 +0200xff0x_(~xff0x@ai066236.d.east.v6connect.net)
2025-04-01 02:02:14 +0200xff0x(~xff0x@ai066236.d.east.v6connect.net) (Ping timeout: 252 seconds)
2025-04-01 02:02:29 +0200unter-oe(~unter-oe@user/unter-oe) (Remote host closed the connection)
2025-04-01 02:02:43 +0200unter-oe(~unter-oe@user/unter-oe) unter-oe
2025-04-01 02:07:19 +0200ryanbooker(uid4340@id-4340.hampstead.irccloud.com) ryanbooker
2025-04-01 02:08:05 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-04-01 02:09:53 +0200zungi(~tory@user/andrewchawk) andrewchawk
2025-04-01 02:10:42 +0200peterbecich(~Thunderbi@syn-047-229-123-186.res.spectrum.com) peterbecich
2025-04-01 02:10:50 +0200SheShePT
2025-04-01 02:12:54 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 260 seconds)
2025-04-01 02:13:37 +0200thorongil(~thorongil@user/thorongil) thorongil
2025-04-01 02:15:58 +0200weary-traveler(~user@user/user363627) (Remote host closed the connection)
2025-04-01 02:19:19 +0200unter-oe(~unter-oe@user/unter-oe) (Ping timeout: 260 seconds)
2025-04-01 02:23:26 +0200merijn(~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 +0200Axma91836(~Axman6@user/axman6) Axman6
2025-04-01 02:28:37 +0200Axman6(~Axman6@user/axman6) (Ping timeout: 250 seconds)
2025-04-01 02:28:38 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 268 seconds)
2025-04-01 02:32:11 +0200cattiesCatGPT
2025-04-01 02:34:03 +0200abrar(~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 +0200merijn(~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 +0200Axma91836Axman6
2025-04-01 02:41:38 +0200xff0x_(~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 +0200Smiles(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 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 245 seconds)
2025-04-01 02:45:00 +0200xff0x(~xff0x@2405:6580:b080:900:9d42:97ad:e5ba:bd56)
2025-04-01 02:47:03 +0200thuna`(~thuna`@user/thuna/x-1480069) thuna`
2025-04-01 02:48:23 +0200 <roconnor> EvanR: yep
2025-04-01 02:48:47 +0200otto_s(~user@p5b044ec8.dip0.t-ipconnect.de) (Ping timeout: 252 seconds)
2025-04-01 02:50:15 +0200xff0x(~xff0x@2405:6580:b080:900:9d42:97ad:e5ba:bd56) (Ping timeout: 246 seconds)
2025-04-01 02:50:24 +0200otto_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 +0200peterbecich(~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 260 seconds)
2025-04-01 02:53:42 +0200malte(~malte@mal.tc) (Remote host closed the connection)
2025-04-01 02:54:02 +0200j1n37-(~j1n37@user/j1n37) j1n37
2025-04-01 02:54:56 +0200j1n37(~j1n37@user/j1n37) (Ping timeout: 244 seconds)
2025-04-01 02:55:03 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-04-01 02:59:30 +0200malte(~malte@mal.tc) malte
2025-04-01 03:01:39 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 244 seconds)
2025-04-01 03:03:39 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-04-01 03:08:22 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 244 seconds)
2025-04-01 03:10:29 +0200hgolden(~hgolden@2603:8000:9d00:3ed1:1b03:b08c:d961:6530) hgolden
2025-04-01 03:11:08 +0200notdabs(~Owner@2600:1700:69cf:9000:6cf0:d644:3911:cb5b) (Quit: Leaving)
2025-04-01 03:13:53 +0200hattckory(~hattckory@bras-base-toroon4524w-grc-30-70-27-118-207.dsl.bell.ca) (Ping timeout: 248 seconds)
2025-04-01 03:18:12 +0200CatGPTcatties
2025-04-01 03:19:22 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-04-01 03:20:39 +0200hughjfchen(~hughjfche@vmi2417424.contaboserver.net) (Quit: WeeChat 4.4.3)
2025-04-01 03:21:49 +0200hughjfchen(~hughjfche@vmi2417424.contaboserver.net) hughjfchen
2025-04-01 03:23:43 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 245 seconds)
2025-04-01 03:24:03 +0200pavonia(~user@user/siracusa) (Quit: Bye!)
2025-04-01 03:27:23 +0200hattckory(~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 +0200peterbecich(~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 +0200hattckory(~hattckory@bras-base-toroon4524w-grc-30-70-27-118-207.dsl.bell.ca) (Ping timeout: 276 seconds)
2025-04-01 03:34:43 +0200thuna`(~thuna`@user/thuna/x-1480069) (Ping timeout: 244 seconds)
2025-04-01 03:34:44 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-04-01 03:35:14 +0200glguygLLMguy
2025-04-01 03:36:20 +0200hattckory(~hattckory@bras-base-toroon4524w-grc-30-70-27-118-207.dsl.bell.ca)
2025-04-01 03:39:22 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 244 seconds)
2025-04-01 03:39:28 +0200xff0x(~xff0x@fsb6a9491c.tkyc517.ap.nuro.jp)
2025-04-01 03:46:52 +0200thorongil(~thorongil@user/thorongil) (Quit: leaving)
2025-04-01 03:50:32 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-04-01 03:55:27 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds)
2025-04-01 04:06:22 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-04-01 04:11:29 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 248 seconds)
2025-04-01 04:13:35 +0200manny68(~manny@2601:445:700:69b0:eea0:8f59:8e82:6460)
2025-04-01 04:16:59 +0200ryanbooker(uid4340@id-4340.hampstead.irccloud.com) (Quit: Connection closed for inactivity)
2025-04-01 04:18:38 +0200machinedgod(~machinedg@d108-173-18-100.abhsia.telus.net) (Ping timeout: 252 seconds)
2025-04-01 04:22:07 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-04-01 04:22:28 +0200peterbecich(~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 245 seconds)
2025-04-01 04:26:39 +0200otto_s(~user@p4ff2724c.dip0.t-ipconnect.de) (Ping timeout: 260 seconds)
2025-04-01 04:27:07 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 244 seconds)
2025-04-01 04:28:02 +0200otto_s(~user@p5b044af5.dip0.t-ipconnect.de)
2025-04-01 04:37:56 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-04-01 04:42:50 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds)
2025-04-01 04:53:43 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-04-01 04:55:40 +0200bitdex(~bitdex@gateway/tor-sasl/bitdex) bitdex
2025-04-01 04:56:58 +0200Unicorn_Princess(~Unicorn_P@user/Unicorn-Princess/x-3540542) Unicorn_Princess
2025-04-01 04:58:44 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 260 seconds)
2025-04-01 05:01:36 +0200troydm(~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 +0200Garbanzo(~Garbanzo@2602:304:6eac:dc10::2e)
2025-04-01 05:09:30 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-04-01 05:14:08 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 245 seconds)
2025-04-01 05:16:32 +0200gmg(~user@user/gehmehgeh) (Remote host closed the connection)
2025-04-01 05:19:05 +0200a_fantom(~fantom@2.219.56.221) (Ping timeout: 244 seconds)
2025-04-01 05:19:35 +0200gmg(~user@user/gehmehgeh) gehmehgeh
2025-04-01 05:25:18 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-04-01 05:29:56 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 244 seconds)
2025-04-01 05:38:02 +0200michalz(~michalz@185.246.207.221)
2025-04-01 05:41:04 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-04-01 05:41:32 +0200peterbecich(~Thunderbi@syn-047-229-123-186.res.spectrum.com) peterbecich
2025-04-01 05:45:59 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 260 seconds)
2025-04-01 05:56:52 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-04-01 06:05:33 +0200zungi(~tory@user/andrewchawk) (Remote host closed the connection)
2025-04-01 06:05:35 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 244 seconds)
2025-04-01 06:05:58 +0200zungi(~tory@user/andrewchawk) andrewchawk
2025-04-01 06:10:19 +0200tavare(~tavare@150.129.88.189)
2025-04-01 06:10:19 +0200tavare(~tavare@150.129.88.189) (Changing host)
2025-04-01 06:10:19 +0200tavare(~tavare@user/tavare) tavare
2025-04-01 06:11:11 +0200peterbecich(~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 252 seconds)
2025-04-01 06:13:27 +0200tavare(~tavare@user/tavare) (Remote host closed the connection)
2025-04-01 06:13:50 +0200tavare(~tavare@150.129.88.189) tavare
2025-04-01 06:13:50 +0200tavare(~tavare@150.129.88.189) (Changing host)
2025-04-01 06:13:50 +0200tavare(~tavare@user/tavare) tavare
2025-04-01 06:13:54 +0200werneta(~werneta@syn-071-083-160-242.res.spectrum.com) werneta
2025-04-01 06:17:05 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-04-01 06:21:19 +0200takuan(~takuan@d8D86B601.access.telenet.be)
2025-04-01 06:22:17 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 265 seconds)
2025-04-01 06:24:12 +0200arahael(~arahael@user/arahael) arahael
2025-04-01 06:24:54 +0200manny68(~manny@2601:445:700:69b0:eea0:8f59:8e82:6460) (Quit: Client closed)
2025-04-01 06:32:52 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-04-01 06:37:36 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds)
2025-04-01 06:45:10 +0200Flow(~none@gentoo/developer/flow) (Ping timeout: 268 seconds)
2025-04-01 06:48:40 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-04-01 06:51:06 +0200tessier(~tessier@ec2-184-72-149-67.compute-1.amazonaws.com) (Remote host closed the connection)
2025-04-01 06:53:39 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 260 seconds)
2025-04-01 06:54:00 +0200Guest52(~Guest52@45.176.88.162)
2025-04-01 06:56:20 +0200Googulator18(~Googulato@178-164-243-34.pool.digikabel.hu)
2025-04-01 06:57:00 +0200Flow(~none@gentoo/developer/flow) flow
2025-04-01 06:58:09 +0200DiegoDD(~diego1234@93.68.153.20)
2025-04-01 06:59:18 +0200Googulator(~Googulato@2a01-036d-0106-01d5-ac5d-24c1-ad5e-7f2b.pool6.digikabel.hu) (Ping timeout: 240 seconds)
2025-04-01 06:59:22 +0200bitdex(~bitdex@gateway/tor-sasl/bitdex) (Remote host closed the connection)
2025-04-01 06:59:47 +0200bitdex(~bitdex@gateway/tor-sasl/bitdex) bitdex
2025-04-01 07:03:02 +0200DiegoDD(~diego1234@93.68.153.20) ()
2025-04-01 07:04:26 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-04-01 07:09:14 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 260 seconds)
2025-04-01 07:09:20 +0200JuanDaugherty(~juan@user/JuanDaugherty) JuanDaugherty
2025-04-01 07:10:49 +0200tessier(~tessier@ip68-8-117-219.sd.sd.cox.net) tessier
2025-04-01 07:15:40 +0200tavare(~tavare@user/tavare) (Remote host closed the connection)
2025-04-01 07:19:49 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-04-01 07:20:22 +0200gAy_DragonAI_Dragon
2025-04-01 07:24:37 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 248 seconds)
2025-04-01 07:28:45 +0200acidjnk_new(~acidjnk@p200300d6e71c4f02f52af534a157a189.dip0.t-ipconnect.de) acidjnk
2025-04-01 07:29:27 +0200internatetional(~nate@2400:9800:f3:3e9a:1832:1a71:b57a:106c) internatetional
2025-04-01 07:31:07 +0200tessier(~tessier@ip68-8-117-219.sd.sd.cox.net) (Ping timeout: 252 seconds)
2025-04-01 07:33:08 +0200tessier(~tessier@ip68-8-117-219.sd.sd.cox.net) tessier
2025-04-01 07:34:16 +0200peterbecich(~Thunderbi@syn-047-229-123-186.res.spectrum.com) peterbecich
2025-04-01 07:35:22 +0200fantom(~fantom@2.219.56.221)
2025-04-01 07:35:33 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-04-01 07:40:24 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds)
2025-04-01 07:51:21 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-04-01 07:52:30 +0200Guest52(~Guest52@45.176.88.162) (Ping timeout: 240 seconds)
2025-04-01 07:56:17 +0200tabaqui(~tabaqui@167.71.80.236) tabaqui
2025-04-01 07:58:33 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 268 seconds)
2025-04-01 08:00:12 +0200peterbecich(~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 252 seconds)
2025-04-01 08:02:18 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-04-01 08:02:57 +0200acarrico(~acarrico@pppoe-209-99-221-107.greenmountainaccess.net) (Ping timeout: 276 seconds)
2025-04-01 08:05:26 +0200acidjnk_new(~acidjnk@p200300d6e71c4f02f52af534a157a189.dip0.t-ipconnect.de) (Ping timeout: 272 seconds)
2025-04-01 08:07:09 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 260 seconds)
2025-04-01 08:12:24 +0200fp(~Thunderbi@wireless-86-50-141-186.open.aalto.fi) fp
2025-04-01 08:17:40 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-04-01 08:18:01 +0200ChaiTRex(~ChaiTRex@user/chaitrex) (Remote host closed the connection)
2025-04-01 08:18:33 +0200ChaiTRex(~ChaiTRex@user/chaitrex) ChaiTRex
2025-04-01 08:21:47 +0200Garbanzo(~Garbanzo@2602:304:6eac:dc10::2e) (Remote host closed the connection)
2025-04-01 08:22:30 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 244 seconds)
2025-04-01 08:27:54 +0200ash3en(~Thunderbi@149.222.150.125) ash3en
2025-04-01 08:28:09 +0200rit(~rit@2409:40e0:101e:42e7:7902:df58:e4a3:373b)
2025-04-01 08:32:48 +0200JuanDaugherty(~juan@user/JuanDaugherty) (Quit: praxis.meansofproduction.biz (juan@acm.org))
2025-04-01 08:33:26 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-04-01 08:36:02 +0200sroso(~sroso@user/SrOso) (Ping timeout: 252 seconds)
2025-04-01 08:38:13 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 248 seconds)
2025-04-01 08:42:00 +0200jjhoo(~jahakala@user/jjhoo) (Ping timeout: 252 seconds)
2025-04-01 08:47:48 +0200sord937(~sord937@gateway/tor-sasl/sord937) sord937
2025-04-01 08:48:11 +0200chele(~chele@user/chele) chele
2025-04-01 08:49:14 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-04-01 08:54:00 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds)
2025-04-01 08:54:04 +0200tromp(~textual@2001:1c00:3487:1b00:29bc:7fae:9d9f:d545)
2025-04-01 08:56:52 +0200CiaoSen(~Jura@2a02:8071:64e1:da0:5a47:caff:fe78:33db) CiaoSen
2025-04-01 09:00:01 +0200caconym(~caconym@user/caconym) (Quit: bye)
2025-04-01 09:01:31 +0200caconym(~caconym@user/caconym) caconym
2025-04-01 09:03:17 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-04-01 09:06:09 +0200acarrico(~acarrico@pppoe-209-99-221-107.greenmountainaccess.net)
2025-04-01 09:08:51 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 268 seconds)
2025-04-01 09:16:17 +0200jmcantrell(~weechat@user/jmcantrell) (Ping timeout: 265 seconds)
2025-04-01 09:16:38 +0200Lord_of_Life_(~Lord@user/lord-of-life/x-2819915) Lord_of_Life
2025-04-01 09:16:39 +0200Lord_of_Life(~Lord@user/lord-of-life/x-2819915) (Ping timeout: 246 seconds)
2025-04-01 09:18:01 +0200Lord_of_Life_Lord_of_Life
2025-04-01 09:19:20 +0200jjhoo(~jahakala@user/jjhoo) jjhoo
2025-04-01 09:22:18 +0200ft(~ft@p508db463.dip0.t-ipconnect.de) (Quit: leaving)
2025-04-01 09:22:30 +0200rit(~rit@2409:40e0:101e:42e7:7902:df58:e4a3:373b) (Ping timeout: 240 seconds)
2025-04-01 09:25:52 +0200internatetional(~nate@2400:9800:f3:3e9a:1832:1a71:b57a:106c) (Ping timeout: 272 seconds)
2025-04-01 09:35:17 +0200internatetional(~nate@2400:9800:f2:615e:1832:218b:fe6e:8b1a) internatetional
2025-04-01 09:38:09 +0200tzh(~tzh@c-76-115-131-146.hsd1.or.comcast.net) (Quit: zzz)
2025-04-01 09:39:54 +0200fp(~Thunderbi@wireless-86-50-141-186.open.aalto.fi) (Ping timeout: 260 seconds)
2025-04-01 09:41:44 +0200j1n37-(~j1n37@user/j1n37) (Read error: Connection reset by peer)
2025-04-01 09:44:42 +0200j1n37(~j1n37@user/j1n37) j1n37
2025-04-01 09:45:58 +0200acidjnk_new(~acidjnk@p200300d6e71c4f8289e7d3d4c6144767.dip0.t-ipconnect.de) acidjnk
2025-04-01 09:46:46 +0200emmanuelux(~emmanuelu@user/emmanuelux) (Read error: Connection reset by peer)
2025-04-01 09:49:32 +0200Sgeo(~Sgeo@user/sgeo) (Read error: Connection reset by peer)
2025-04-01 09:55:19 +0200machinedgod(~machinedg@d108-173-18-100.abhsia.telus.net) machinedgod
2025-04-01 09:55:36 +0200zmt00(~zmt00@user/zmt00) (Ping timeout: 252 seconds)
2025-04-01 09:58:39 +0200Square(~Square4@user/square) Square
2025-04-01 09:59:07 +0200aforemny(~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 +0200merijn(~merijn@77.242.116.146) merijn
2025-04-01 10:06:24 +0200ash3en(~Thunderbi@149.222.150.125) (Ping timeout: 272 seconds)
2025-04-01 10:15:35 +0200unter-oe(~unter-oe@176.192.243.31) unter-oe
2025-04-01 10:15:35 +0200unter-oe(~unter-oe@176.192.243.31) (Changing host)
2025-04-01 10:15:35 +0200unter-oe(~unter-oe@user/unter-oe) unter-oe
2025-04-01 10:16:19 +0200ash3en(~Thunderbi@149.222.150.125) ash3en
2025-04-01 10:16:33 +0200unter-oe(~unter-oe@user/unter-oe) (Remote host closed the connection)
2025-04-01 10:18:08 +0200pavonia(~user@user/siracusa) siracusa
2025-04-01 10:19:33 +0200merijn(~merijn@77.242.116.146) (Ping timeout: 245 seconds)
2025-04-01 10:23:03 +0200lisbeths(uid135845@id-135845.lymington.irccloud.com) lisbeths
2025-04-01 10:27:36 +0200merijn(~merijn@77.242.116.146) merijn
2025-04-01 10:28:09 +0200unter-oe(~unter-oe@176.192.243.31)
2025-04-01 10:28:09 +0200unter-oe(~unter-oe@176.192.243.31) (Changing host)
2025-04-01 10:28:09 +0200unter-oe(~unter-oe@user/unter-oe) unter-oe
2025-04-01 10:33:44 +0200ash3en(~Thunderbi@149.222.150.125) (Ping timeout: 252 seconds)
2025-04-01 10:39:29 +0200unter-oe(~unter-oe@user/unter-oe) (Remote host closed the connection)
2025-04-01 10:39:43 +0200unter-oe(~unter-oe@user/unter-oe) unter-oe
2025-04-01 10:39:47 +0200unter-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 +0200Smiles(uid551636@id-551636.lymington.irccloud.com) Smiles
2025-04-01 10:47:52 +0200ash3en(~Thunderbi@149.222.150.125) ash3en
2025-04-01 10:52:25 +0200ash3en(~Thunderbi@149.222.150.125) (Ping timeout: 252 seconds)
2025-04-01 10:53:36 +0200califax(~califax@user/califx) (Ping timeout: 264 seconds)
2025-04-01 10:54:00 +0200lxsameer(~lxsameer@Serene/lxsameer) lxsameer
2025-04-01 10:54:13 +0200califax(~califax@user/califx) califx
2025-04-01 10:56:50 +0200fp(~Thunderbi@wireless-86-50-141-186.open.aalto.fi) fp
2025-04-01 11:07:49 +0200internatetional(~nate@2400:9800:f2:615e:1832:218b:fe6e:8b1a) (Ping timeout: 260 seconds)
2025-04-01 11:18:58 +0200dhil(~dhil@2a0c:b381:52e:3600:a9d5:fde7:3316:82e2) dhil
2025-04-01 11:22:33 +0200ash3en(~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 +0200ash3en(~Thunderbi@149.222.150.125) (Ping timeout: 260 seconds)
2025-04-01 11:35:19 +0200internatetional(~nate@2400:9800:170:c23:1:0:419:21ae) internatetional
2025-04-01 11:57:42 +0200jathan(~jathan@69.61.93.38) (Ping timeout: 252 seconds)
2025-04-01 12:00:51 +0200m5zs7k(aquares@web10.mydevil.net) (Ping timeout: 276 seconds)
2025-04-01 12:02:49 +0200fp(~Thunderbi@wireless-86-50-141-186.open.aalto.fi) (Ping timeout: 260 seconds)
2025-04-01 12:02:59 +0200j1n37-(~j1n37@user/j1n37) j1n37
2025-04-01 12:04:05 +0200j1n37(~j1n37@user/j1n37) (Ping timeout: 248 seconds)
2025-04-01 12:15:01 +0200unter-oe(~unter-oe@176.192.243.31)
2025-04-01 12:15:01 +0200unter-oe(~unter-oe@176.192.243.31) (Changing host)
2025-04-01 12:15:01 +0200unter-oe(~unter-oe@user/unter-oe) unter-oe
2025-04-01 12:20:26 +0200m5zs7k(aquares@web10.mydevil.net) m5zs7k
2025-04-01 12:21:04 +0200unter-oe(~unter-oe@user/unter-oe) (Remote host closed the connection)
2025-04-01 12:22:55 +0200unter-oe(~unter-oe@176.192.243.31) unter-oe
2025-04-01 12:22:55 +0200unter-oe(~unter-oe@176.192.243.31) (Changing host)
2025-04-01 12:22:55 +0200unter-oe(~unter-oe@user/unter-oe) unter-oe
2025-04-01 12:23:09 +0200forell(~forell@user/forell) forell
2025-04-01 12:23:39 +0200sord937(~sord937@gateway/tor-sasl/sord937) (Remote host closed the connection)
2025-04-01 12:23:50 +0200merijn(~merijn@77.242.116.146) (Ping timeout: 272 seconds)
2025-04-01 12:24:11 +0200sord937(~sord937@gateway/tor-sasl/sord937) sord937
2025-04-01 12:26:22 +0200xff0x(~xff0x@fsb6a9491c.tkyc517.ap.nuro.jp) (Ping timeout: 244 seconds)
2025-04-01 12:26:32 +0200fp(~Thunderbi@2001:708:150:10::1d80) fp
2025-04-01 12:27:12 +0200unter-oe(~unter-oe@user/unter-oe) (Remote host closed the connection)
2025-04-01 12:27:33 +0200unter-oe(~unter-oe@176.192.243.31)
2025-04-01 12:27:33 +0200unter-oe(~unter-oe@176.192.243.31) (Changing host)
2025-04-01 12:27:33 +0200unter-oe(~unter-oe@user/unter-oe) unter-oe
2025-04-01 12:29:10 +0200unter-oe(~unter-oe@user/unter-oe) (Remote host closed the connection)
2025-04-01 12:30:46 +0200merijn(~merijn@77.242.116.146) merijn
2025-04-01 12:31:24 +0200unter-oe(~unter-oe@user/unter-oe) unter-oe
2025-04-01 12:35:09 +0200merijn(~merijn@77.242.116.146) (Ping timeout: 244 seconds)
2025-04-01 12:42:17 +0200lisbeths(uid135845@id-135845.lymington.irccloud.com) (Quit: Connection closed for inactivity)
2025-04-01 12:48:00 +0200merijn(~merijn@77.242.116.146) merijn
2025-04-01 12:50:46 +0200sord937(~sord937@gateway/tor-sasl/sord937) (Remote host closed the connection)
2025-04-01 12:51:06 +0200sord937(~sord937@gateway/tor-sasl/sord937) sord937
2025-04-01 12:52:05 +0200acidjnk_new(~acidjnk@p200300d6e71c4f8289e7d3d4c6144767.dip0.t-ipconnect.de) (Ping timeout: 248 seconds)
2025-04-01 12:53:50 +0200unter-oe(~unter-oe@user/unter-oe) (Remote host closed the connection)
2025-04-01 12:53:56 +0200jathan(~jathan@69.61.93.38) jathan
2025-04-01 12:54:09 +0200acidjnk_new(~acidjnk@p200300d6e71c4f8289e7d3d4c6144767.dip0.t-ipconnect.de)
2025-04-01 12:54:50 +0200ash3en(~Thunderbi@149.222.150.125) ash3en
2025-04-01 12:58:48 +0200internatetional(~nate@2400:9800:170:c23:1:0:419:21ae) (Quit: CoreIRC for Android - www.coreirc.com)
2025-04-01 12:59:06 +0200merijn(~merijn@77.242.116.146) (Ping timeout: 265 seconds)
2025-04-01 13:00:05 +0200caconym(~caconym@user/caconym) (Quit: bye)
2025-04-01 13:02:20 +0200caconym(~caconym@user/caconym) caconym
2025-04-01 13:05:01 +0200merijn(~merijn@77.242.116.146) merijn
2025-04-01 13:06:01 +0200Smiles(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 +0200tromp(~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 +0200xff0x(~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 +0200toby-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 +0200tromp(~textual@2001:1c00:3487:1b00:29bc:7fae:9d9f:d545)
2025-04-01 13:41:09 +0200merijn(~merijn@77.242.116.146) (Ping timeout: 248 seconds)
2025-04-01 13:44:21 +0200merijn(~merijn@77.242.116.146) merijn
2025-04-01 13:45:58 +0200__monty__(~toonn@user/toonn) toonn
2025-04-01 13:46:13 +0200tromp(~textual@2001:1c00:3487:1b00:29bc:7fae:9d9f:d545) (Quit: My iMac has gone to sleep. ZZZzzz…)
2025-04-01 13:46:48 +0200fp(~Thunderbi@2001:708:150:10::1d80) (Ping timeout: 272 seconds)
2025-04-01 13:57:28 +0200tremon(~tremon@83.80.159.219) tremon
2025-04-01 14:00:51 +0200Smiles(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 +0200jespada(~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 +0200JuanDaugherty(~juan@user/JuanDaugherty) JuanDaugherty
2025-04-01 14:20:15 +0200srk(~sorki@user/srk) (Ping timeout: 244 seconds)
2025-04-01 14:21:30 +0200merijn(~merijn@77.242.116.146) (Ping timeout: 246 seconds)
2025-04-01 14:25:24 +0200Googulator18(~Googulato@178-164-243-34.pool.digikabel.hu) (Quit: Client closed)
2025-04-01 14:25:42 +0200Googulator18(~Googulato@2a01-036d-0106-211a-ac5d-24c1-ad5e-7f2b.pool6.digikabel.hu)
2025-04-01 14:33:27 +0200merijn(~merijn@77.242.116.146) merijn
2025-04-01 14:33:31 +0200srk(~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 +0200JuanDaugherty(~juan@user/JuanDaugherty) (Quit: praxis.meansofproduction.biz (juan@acm.org))
2025-04-01 14:41:43 +0200jespada(~jespada@2800:a4:2256:6500:9933:8787:b375:7c3e) (Quit: My Mac has gone to sleep. ZZZzzz…)
2025-04-01 14:46:24 +0200zungi(~tory@user/andrewchawk) (Ping timeout: 264 seconds)
2025-04-01 14:50:55 +0200zungi(~tory@user/andrewchawk) andrewchawk
2025-04-01 14:51:27 +0200bitdex(~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 +0200Googulator18(~Googulato@2a01-036d-0106-211a-ac5d-24c1-ad5e-7f2b.pool6.digikabel.hu) (Quit: Client closed)
2025-04-01 15:05:28 +0200Googulator18(~Googulato@2a01-036d-0106-211a-ac5d-24c1-ad5e-7f2b.pool6.digikabel.hu)
2025-04-01 15:06:51 +0200comerijn(~merijn@77.242.116.146) merijn
2025-04-01 15:10:05 +0200merijn(~merijn@77.242.116.146) (Ping timeout: 265 seconds)
2025-04-01 15:13:38 +0200fp(~Thunderbi@2001:708:150:10::1d80) fp
2025-04-01 15:14:59 +0200tromp(~textual@2001:1c00:3487:1b00:29bc:7fae:9d9f:d545)
2025-04-01 15:22:22 +0200Digitteknohippie(~user@user/digit) Digit
2025-04-01 15:23:04 +0200Digit(~user@user/digit) (Ping timeout: 272 seconds)
2025-04-01 15:23:43 +0200CiaoSen(~Jura@2a02:8071:64e1:da0:5a47:caff:fe78:33db) (Ping timeout: 245 seconds)
2025-04-01 15:33:01 +0200notdabs(~Owner@2600:1700:69cf:9000:553a:e935:8c4f:3651)
2025-04-01 15:37:11 +0200Otong(~Otong@user/Otong) Otong
2025-04-01 15:37:40 +0200Otong(~Otong@user/Otong) (Remote host closed the connection)
2025-04-01 15:38:19 +0200Otong(~Otong@user/Otong) Otong
2025-04-01 15:38:28 +0200Otong(~Otong@user/Otong) (Remote host closed the connection)
2025-04-01 15:43:17 +0200acidjnk_new(~acidjnk@p200300d6e71c4f8289e7d3d4c6144767.dip0.t-ipconnect.de) (Ping timeout: 248 seconds)
2025-04-01 15:47:52 +0200fantom(~fantom@2.219.56.221) (Ping timeout: 244 seconds)
2025-04-01 15:48:24 +0200rit(~rit@2409:40e0:101e:42e7:101c:ea47:4905:baf6)
2025-04-01 15:48:24 +0200rit(~rit@2409:40e0:101e:42e7:101c:ea47:4905:baf6) (Remote host closed the connection)
2025-04-01 15:48:32 +0200rit(~rit@2409:40e0:101e:42e7:101c:ea47:4905:baf6)
2025-04-01 15:49:11 +0200DigitteknohippieDigit
2025-04-01 15:54:16 +0200fantom(~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 +0200Leary(~Leary@user/Leary/x-0910699) (Ping timeout: 268 seconds)
2025-04-01 16:02:57 +0200comerijn(~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 +0200ash3en(~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 +0200merijn(~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 +0200Googulator18(~Googulato@2a01-036d-0106-211a-ac5d-24c1-ad5e-7f2b.pool6.digikabel.hu) (Quit: Client closed)
2025-04-01 16:10:00 +0200Googulator18(~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 +0200mari-estel(~mari-este@user/mari-estel) mari-estel
2025-04-01 16:17:11 +0200weary-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 +0200acidjnk_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 +0200Leary(~Leary@user/Leary/x-0910699) Leary
2025-04-01 16:30:39 +0200Digitteknohippie(~user@user/digit) Digit
2025-04-01 16:33:28 +0200Digit(~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 +0200gLLMguyglguy
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 +0200rit(~rit@2409:40e0:101e:42e7:101c:ea47:4905:baf6) (Ping timeout: 240 seconds)
2025-04-01 16:47:22 +0200longlongdouble(~longlongd@2405:201:5c16:894:2d75:fd2d:c031:9b09)
2025-04-01 16:47:27 +0200longlongdouble(~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 +0200jmcantrell(~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 +0200DigitteknohippieDigit
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 +0200gmg(~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 +0200gehmehgeh(~user@user/gehmehgeh) gehmehgeh
2025-04-01 16:54:48 +0200mari-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 +0200ubert(~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 +0200acidjnk_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 +0200kawzeg(kawzeg@2a01:7e01::f03c:92ff:fee2:ec34) kawzeg
2025-04-01 17:17:42 +0200acidjnk_new(~acidjnk@p200300d6e71c4f82640579a6e00084b6.dip0.t-ipconnect.de) acidjnk
2025-04-01 17:19:12 +0200tzh(~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 +0200werneta(~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 +0200tromp(~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 +0200Googulator18(~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 +0200rvalue(~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 +0200Googulator18(~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 +0200rvalue(~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 +0200mari-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 +0200CiaoSen(~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 +0200fp(~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 +0200XZDX(~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 +0200segfaultfizzbuzz(~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 +0200tromp(~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 +0200mari-estel(~mari-este@user/mari-estel) (Remote host closed the connection)
2025-04-01 17:54:33 +0200tomsmeding. o O ( no, the original yahb was run by mni'ip (without the '; wanted to avoid a ping) )
2025-04-01 17:56:01 +0200Smiles(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 +0200CiaoSen(~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 +0200tomsmedingsuspects 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 +0200tomsmedingis afk for a while
2025-04-01 18:11:51 +0200haskellbridge(~hackager@syn-024-093-192-219.res.spectrum.com) (Remote host closed the connection)
2025-04-01 18:12:02 +0200peterbecich(~Thunderbi@syn-047-229-123-186.res.spectrum.com) peterbecich
2025-04-01 18:14:48 +0200haskellbridge(~hackager@syn-024-093-192-219.res.spectrum.com) hackager
2025-04-01 18:14:48 +0200ChanServ+v haskellbridge
2025-04-01 18:15:32 +0200danza(~danza@user/danza) danza
2025-04-01 18:19:59 +0200merijn(~merijn@77.242.116.146) (Ping timeout: 244 seconds)
2025-04-01 18:20:33 +0200machinedgod(~machinedg@d108-173-18-100.abhsia.telus.net) (Ping timeout: 248 seconds)
2025-04-01 18:24:53 +0200aman(~aman@user/aman) (Ping timeout: 252 seconds)
2025-04-01 18:26:55 +0200aman(~aman@user/aman) aman
2025-04-01 18:29:18 +0200peterbecich(~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 246 seconds)
2025-04-01 18:29:42 +0200peterbecich(~Thunderbi@syn-047-229-123-186.res.spectrum.com) peterbecich
2025-04-01 18:31:18 +0200danza(~danza@user/danza) (Remote host closed the connection)
2025-04-01 18:34:45 +0200peterbecich(~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 276 seconds)
2025-04-01 18:35:05 +0200kawzeg(kawzeg@2a01:7e01::f03c:92ff:fee2:ec34) (Quit: WeeChat 4.3.0)
2025-04-01 18:38:58 +0200peterbecich(~Thunderbi@syn-047-229-123-186.res.spectrum.com) peterbecich
2025-04-01 18:42:59 +0200kawzeg(kawzeg@2a01:7e01::f03c:92ff:fee2:ec34) kawzeg
2025-04-01 18:45:14 +0200ubert(~Thunderbi@2a02:8109:ab8a:5a00:74f1:1caf:2629:a3c8) (Remote host closed the connection)
2025-04-01 18:46:06 +0200acidjnk_new(~acidjnk@p200300d6e71c4f82640579a6e00084b6.dip0.t-ipconnect.de) (Ping timeout: 246 seconds)
2025-04-01 18:52:45 +0200ft(~ft@p508db463.dip0.t-ipconnect.de) ft
2025-04-01 18:57:24 +0200ft(~ft@p508db463.dip0.t-ipconnect.de) (Client Quit)
2025-04-01 18:59:14 +0200ft(~ft@p508db463.dip0.t-ipconnect.de) ft
2025-04-01 19:06:48 +0200CiaoSen(~Jura@2a02:8071:64e1:da0:5a47:caff:fe78:33db) CiaoSen
2025-04-01 19:10:31 +0200Natch(~natch@c-92-34-7-158.bbcust.telenor.se) (Remote host closed the connection)
2025-04-01 19:14:36 +0200zungi(~tory@user/andrewchawk) (Ping timeout: 264 seconds)
2025-04-01 19:15:56 +0200Smiles(uid551636@id-551636.lymington.irccloud.com) Smiles
2025-04-01 19:16:18 +0200peterbecich(~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 244 seconds)
2025-04-01 19:16:47 +0200kawzeg(kawzeg@2a01:7e01::f03c:92ff:fee2:ec34) (Quit: WeeChat 4.3.0)
2025-04-01 19:19:00 +0200CiaoSen(~Jura@2a02:8071:64e1:da0:5a47:caff:fe78:33db) (Ping timeout: 246 seconds)
2025-04-01 19:21:40 +0200kawzeg(~finn@2a01:4f9:c013:cfbf::1) kawzeg
2025-04-01 19:29:08 +0200ash3en(~Thunderbi@ip1f10cbd6.dynamic.kabel-deutschland.de) ash3en
2025-04-01 19:29:19 +0200tromp(~textual@2001:1c00:3487:1b00:29bc:7fae:9d9f:d545) (Quit: My iMac has gone to sleep. ZZZzzz…)
2025-04-01 19:29:19 +0200peterbecich(~Thunderbi@syn-047-229-123-186.res.spectrum.com) peterbecich
2025-04-01 19:29:31 +0200kawzeg(~finn@2a01:4f9:c013:cfbf::1) (Quit: WeeChat 4.6.0)
2025-04-01 19:29:55 +0200kawzeg(~finn@2a01:4f9:c013:cfbf::1) kawzeg
2025-04-01 19:34:26 +0200kawzeg(~finn@2a01:4f9:c013:cfbf::1) (Client Quit)
2025-04-01 19:37:41 +0200driib318(~driib@vmi931078.contaboserver.net) (Quit: The Lounge - https://thelounge.chat)
2025-04-01 19:37:51 +0200peterbecich(~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 252 seconds)
2025-04-01 19:40:15 +0200driib318(~driib@vmi931078.contaboserver.net) driib
2025-04-01 19:42:47 +0200zungi(~tory@user/andrewchawk) andrewchawk
2025-04-01 19:44:30 +0200tromp(~textual@2001:1c00:3487:1b00:29bc:7fae:9d9f:d545)
2025-04-01 19:47:14 +0200euphores(~SASL_euph@user/euphores) euphores
2025-04-01 19:47:21 +0200kawzeg(~finn@2a01:4f9:c013:cfbf::1) kawzeg
2025-04-01 19:48:12 +0200chele(~chele@user/chele) (Remote host closed the connection)
2025-04-01 19:51:10 +0200kawzeg(~finn@2a01:4f9:c013:cfbf::1) (Client Quit)
2025-04-01 19:51:27 +0200kawzeg(kawzeg@2a01:4f9:c013:cfbf::1) kawzeg
2025-04-01 19:52:03 +0200kawzeg(kawzeg@2a01:4f9:c013:cfbf::1) (Client Quit)
2025-04-01 19:53:42 +0200CiaoSen(~Jura@2a02:8071:64e1:da0:5a47:caff:fe78:33db) CiaoSen
2025-04-01 19:55:29 +0200kawzeg(kawzeg@2a01:4f9:c013:cfbf::1) kawzeg