IRCBrowse

2026/01/23

2026-01-23 00:02:18 +0100merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 256 seconds)
2026-01-23 00:03:18 +0100__monty__(~toonn@user/toonn) (Quit: leaving)
2026-01-23 00:04:51 +0100zanetti(~zanetti@2804:7f0:9b80:2edc:c121:46e7:c35f:46cf) zanetti
2026-01-23 00:13:09 +0100merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn
2026-01-23 00:14:16 +0100 <jackdk> Perhaps most approachable free intro. Optics By Example is worth the price.
2026-01-23 00:18:12 +0100trickard_(~trickard@cpe-93-98-47-163.wireline.com.au) (Read error: Connection reset by peer)
2026-01-23 00:18:26 +0100trickard_(~trickard@cpe-93-98-47-163.wireline.com.au)
2026-01-23 00:20:24 +0100 <chromoblob> how the fuck are you supposed to write Haskell without recursion
2026-01-23 00:20:25 +0100merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 264 seconds)
2026-01-23 00:20:52 +0100 <chromoblob> and how is Haskell without recursion supposed to be useful
2026-01-23 00:23:28 +0100 <geekosaur> I think tht usually means without _explicit_ recursion, e.g. using folds/traverses
2026-01-23 00:28:53 +0100zanetti(~zanetti@2804:7f0:9b80:2edc:c121:46e7:c35f:46cf) (Quit: Konversation terminated!)
2026-01-23 00:33:34 +0100trickard_(~trickard@cpe-93-98-47-163.wireline.com.au) (Ping timeout: 244 seconds)
2026-01-23 00:34:08 +0100trickard_(~trickard@cpe-93-98-47-163.wireline.com.au)
2026-01-23 00:34:18 +0100 <jreicher> chromoblob: who's saying you should write Haskell without recursion?
2026-01-23 00:34:30 +0100Hafydd(~Hafydd@user/hafydd) (Quit: WeeChat 4.8.1)
2026-01-23 00:40:35 +0100humasect(~humasect@dyn-192-249-132-90.nexicom.net) humasect
2026-01-23 00:42:00 +0100humasect(~humasect@dyn-192-249-132-90.nexicom.net) (Remote host closed the connection)
2026-01-23 00:47:48 +0100RMSBach(~RMSBach@24.210.9.182) RMSBach
2026-01-23 00:50:23 +0100merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn
2026-01-23 00:50:25 +0100vanishingideal(~vanishing@user/vanishingideal) (Ping timeout: 264 seconds)
2026-01-23 00:51:03 +0100vanishingideal(~vanishing@user/vanishingideal) vanishingideal
2026-01-23 00:55:03 +0100Hafydd(~Hafydd@user/hafydd) Hafydd
2026-01-23 00:56:36 +0100Square3(~Square4@user/square) Square
2026-01-23 01:00:06 +0100merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 256 seconds)
2026-01-23 01:10:11 +0100 <EvanR> the answer the question, certain patterns of recursion can be encapulsated in combinators that magically have the same effect
2026-01-23 01:10:13 +0100 <EvanR> to
2026-01-23 01:10:31 +0100 <EvanR> e.g. map and fold
2026-01-23 01:10:42 +0100 <EvanR> they can't do everything, but the more such tools you have the more you can do
2026-01-23 01:10:58 +0100 <EvanR> but sometimes explicit recursion makes more sense
2026-01-23 01:11:28 +0100merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn
2026-01-23 01:16:39 +0100 <probie> how are imperative languages without goto supposed to be useful?
2026-01-23 01:16:39 +0100merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 265 seconds)
2026-01-23 01:25:31 +0100Zemy_(~Zemy@2600:100c:b0ab:ed8b:c474:c7ff:febb:8ed3)
2026-01-23 01:27:14 +0100merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn
2026-01-23 01:28:13 +0100Zemy(~Zemy@72.178.108.235) (Ping timeout: 246 seconds)
2026-01-23 01:32:00 +0100merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 245 seconds)
2026-01-23 01:33:28 +0100trickard_(~trickard@cpe-93-98-47-163.wireline.com.au) (Read error: Connection reset by peer)
2026-01-23 01:33:42 +0100trickard_(~trickard@cpe-93-98-47-163.wireline.com.au)
2026-01-23 01:43:02 +0100merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn
2026-01-23 01:48:16 +0100merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 256 seconds)
2026-01-23 01:51:32 +0100Zemy(~Zemy@syn-192-154-181-091.biz.spectrum.com)
2026-01-23 01:55:54 +0100Zemy_(~Zemy@2600:100c:b0ab:ed8b:c474:c7ff:febb:8ed3) (Ping timeout: 260 seconds)
2026-01-23 01:56:13 +0100Square3(~Square4@user/square) (Ping timeout: 246 seconds)
2026-01-23 01:58:49 +0100merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn
2026-01-23 02:01:45 +0100Zemy_(~Zemy@2600:100c:b0ab:ed8b:9876:2aff:fe33:1a1d)
2026-01-23 02:03:37 +0100Zemy(~Zemy@syn-192-154-181-091.biz.spectrum.com) (Ping timeout: 264 seconds)
2026-01-23 02:03:49 +0100merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 250 seconds)
2026-01-23 02:05:55 +0100 <systemfault> for loops/while/etc...
2026-01-23 02:07:45 +0100humasect(~humasect@dyn-192-249-132-90.nexicom.net) humasect
2026-01-23 02:08:40 +0100 <jackdk> I think probie is asking rhetorically, to provide an analogous question/answer pair to chromoblob/EvanR.
2026-01-23 02:08:58 +0100 <EvanR> lol
2026-01-23 02:09:57 +0100 <EvanR> clearly systemfault is answering in such a way intentionally to highlight the irony
2026-01-23 02:10:53 +0100 <EvanR> this is what it's like in the tiplerian omega point simulation where everyone already knows everything anyone could talk about
2026-01-23 02:11:35 +0100 <systemfault> Yeah... that said, I don't know what a tiplerian omega point simulation is...
2026-01-23 02:13:14 +0100 <geekosaur> sounds to me like someone's been tippling on physics 🙂
2026-01-23 02:14:37 +0100merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn
2026-01-23 02:15:37 +0100xff0x(~xff0x@2405:6580:b080:900:52f9:378c:6eea:47d5) (Ping timeout: 265 seconds)
2026-01-23 02:17:50 +0100Pozyomka_(~pyon@user/pyon) (Ping timeout: 245 seconds)
2026-01-23 02:19:41 +0100Pozyomka(~pyon@user/pyon) pyon
2026-01-23 02:19:49 +0100merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 264 seconds)
2026-01-23 02:21:54 +0100ljdarj(~Thunderbi@user/ljdarj) (Ping timeout: 265 seconds)
2026-01-23 02:30:02 +0100Zemy(~Zemy@72.178.108.235)
2026-01-23 02:30:17 +0100merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn
2026-01-23 02:31:59 +0100Zemy_(~Zemy@2600:100c:b0ab:ed8b:9876:2aff:fe33:1a1d) (Ping timeout: 250 seconds)
2026-01-23 02:35:26 +0100merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 265 seconds)
2026-01-23 02:39:37 +0100Square2(~Square@user/square) (Ping timeout: 264 seconds)
2026-01-23 02:42:24 +0100Inline(~User@2001-4dd7-bc56-0-fdb7-c703-fc72-e0a.ipv6dyn.netcologne.de) (Ping timeout: 252 seconds)
2026-01-23 02:43:44 +0100omidmash3(~omidmash@user/omidmash) omidmash
2026-01-23 02:45:34 +0100omidmash(~omidmash@user/omidmash) (Ping timeout: 246 seconds)
2026-01-23 02:45:34 +0100omidmash3omidmash
2026-01-23 02:46:04 +0100merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn
2026-01-23 02:50:36 +0100merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 256 seconds)
2026-01-23 02:54:36 +0100Inline(~User@2001-4dd7-bc56-0-bf4e-84aa-8c9c-590c.ipv6dyn.netcologne.de) Inline
2026-01-23 03:01:29 +0100merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn
2026-01-23 03:08:07 +0100merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 240 seconds)
2026-01-23 03:10:07 +0100 <Leary> chromoblob: Write all your co/inductive co/data types in greatest/least-fixed-point form, and all your logic in folds. It's not even as bad as it sounds!
2026-01-23 03:11:43 +0100humasect(~humasect@dyn-192-249-132-90.nexicom.net) (Quit: Leaving...)
2026-01-23 03:13:51 +0100xff0x(~xff0x@fsb6a9491c.tkyc517.ap.nuro.jp)
2026-01-23 03:19:31 +0100merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn
2026-01-23 03:24:25 +0100merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 246 seconds)
2026-01-23 03:33:01 +0100 <jackdk> Reminds me of Dhall
2026-01-23 03:35:18 +0100merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn
2026-01-23 03:40:12 +0100merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 265 seconds)
2026-01-23 03:41:30 +0100terrorjack(~terrorjac@2a01:4f8:c17:9d11::) terrorjack
2026-01-23 03:41:32 +0100vanishingideal(~vanishing@user/vanishingideal) (Ping timeout: 244 seconds)
2026-01-23 03:43:36 +0100vanishingideal(~vanishing@user/vanishingideal) vanishingideal
2026-01-23 03:47:59 +0100 <Leary> It should; Haskell sans recursion ~ System F ~ Dhall.
2026-01-23 03:51:54 +0100omidmash(~omidmash@user/omidmash) (Quit: The Lounge - https://thelounge.chat)
2026-01-23 03:52:25 +0100mange(~mange@user/mange) (Quit: Quittin' time!)
2026-01-23 03:53:09 +0100merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn
2026-01-23 03:53:09 +0100trickard_trickard
2026-01-23 03:55:29 +0100omidmash(~omidmash@user/omidmash) omidmash
2026-01-23 03:57:25 +0100haskellbridge(~hackager@96.28.224.214) (Remote host closed the connection)
2026-01-23 03:57:40 +0100merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 246 seconds)
2026-01-23 03:57:59 +0100haskellbridge(~hackager@96.28.224.214) hackager
2026-01-23 03:57:59 +0100ChanServ+v haskellbridge
2026-01-23 04:08:31 +0100merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn
2026-01-23 04:13:49 +0100merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 264 seconds)
2026-01-23 04:22:02 +0100notzmv(~umar@user/notzmv) notzmv
2026-01-23 04:23:03 +0100haskellbridge(~hackager@96.28.224.214) (Remote host closed the connection)
2026-01-23 04:24:18 +0100merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn
2026-01-23 04:26:58 +0100foul_owl(~kerry@94.156.149.99) (Ping timeout: 260 seconds)
2026-01-23 04:29:43 +0100merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 264 seconds)
2026-01-23 04:34:12 +0100haskellbridge(~hackager@96.28.224.214) hackager
2026-01-23 04:34:12 +0100ChanServ+v haskellbridge
2026-01-23 04:38:57 +0100Googulator26Googulator
2026-01-23 04:40:05 +0100merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn
2026-01-23 04:41:09 +0100foul_owl(~kerry@94.156.149.91) foul_owl
2026-01-23 04:45:05 +0100merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 244 seconds)
2026-01-23 04:45:26 +0100 <haskellbridge> <Zemyla> You can even zip lists by folding over both of them.
2026-01-23 04:51:58 +0100rotcev(~rotcev@user/rotcev) (Quit: Client closed)
2026-01-23 04:53:28 +0100chenjf(~chenjf@68.64.178.54)
2026-01-23 04:55:05 +0100 <monochrom> Belated: My hot take: How are languages without call/cc or at least shift/reset supposed to be useful? >:)
2026-01-23 04:55:07 +0100vanishingideal(~vanishing@user/vanishingideal) (Ping timeout: 265 seconds)
2026-01-23 04:55:34 +0100chenjf(~chenjf@68.64.178.54) (Client Quit)
2026-01-23 04:55:54 +0100merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn
2026-01-23 04:58:30 +0100leah2(~leah@vuxu.org) (Ping timeout: 265 seconds)
2026-01-23 05:00:19 +0100merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 246 seconds)
2026-01-23 05:04:31 +0100notzmv(~umar@user/notzmv) (Ping timeout: 264 seconds)
2026-01-23 05:11:16 +0100merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn
2026-01-23 05:16:13 +0100merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 250 seconds)
2026-01-23 05:16:35 +0100machinedgod(~machinedg@d75-159-126-101.abhsia.telus.net) (Ping timeout: 245 seconds)
2026-01-23 05:17:51 +0100 <probie> Zemyla: You don't need to fold over both them, just one
2026-01-23 05:23:07 +0100merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn
2026-01-23 05:23:20 +0100 <probie> > let zip' = foldr (\x k ys -> case ys of { [] -> []; y:ys' -> (x,y):k ys' }) (const []) in zip' "hello" "world!"
2026-01-23 05:23:21 +0100 <lambdabot> [('h','w'),('e','o'),('l','r'),('l','l'),('o','d')]
2026-01-23 05:24:15 +0100sp1ff`(~user@2601:1c2:4701:900::32d4) (Read error: Connection reset by peer)
2026-01-23 05:24:52 +0100sp1ff`(~user@2601:1c2:4701:900::32d4)
2026-01-23 05:28:08 +0100merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 256 seconds)
2026-01-23 05:29:11 +0100 <ncf> well, case ys is a fold, just not a recursive one
2026-01-23 05:31:54 +0100trickard(~trickard@cpe-93-98-47-163.wireline.com.au) (Read error: Connection reset by peer)
2026-01-23 05:32:05 +0100 <probie> It's a lesser fold. A crease? :p
2026-01-23 05:32:08 +0100trickard_(~trickard@cpe-93-98-47-163.wireline.com.au)
2026-01-23 05:32:22 +0100peterbecich(~Thunderbi@71.84.33.135) peterbecich
2026-01-23 05:33:16 +0100 <ncf> i will concede 'a ply'
2026-01-23 05:38:32 +0100sp1ff`(~user@2601:1c2:4701:900::32d4) (Read error: Connection reset by peer)
2026-01-23 05:38:54 +0100merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn
2026-01-23 05:39:13 +0100sp1ff`(~user@2601:1c2:4701:900::32d4)
2026-01-23 05:43:59 +0100merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 260 seconds)
2026-01-23 05:48:55 +0100dutchie(~dutchie@user/dutchie) (Ping timeout: 264 seconds)
2026-01-23 05:50:14 +0100peterbecich(~Thunderbi@71.84.33.135) (Ping timeout: 256 seconds)
2026-01-23 05:50:48 +0100chromoblob(~chromoblo@user/chromob1ot1c) (Ping timeout: 256 seconds)
2026-01-23 05:51:25 +0100chromoblob(~chromoblo@user/chromob1ot1c) chromoblob\0
2026-01-23 05:54:42 +0100merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn
2026-01-23 05:54:50 +0100 <haskellbridge> <Zemyla> @let newtype Z a b = Z { runZ :: a -> (Z a b -> b) -> b }
2026-01-23 05:55:20 +0100 <haskellbridge> <Zemyla> Apparently lambdabot doesn't like the bridge.
2026-01-23 05:58:31 +0100chromoblob(~chromoblo@user/chromob1ot1c) (Read error: Connection reset by peer)
2026-01-23 06:00:29 +0100chromoblob(~chromoblo@user/chromob1ot1c) chromoblob\0
2026-01-23 06:01:49 +0100merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 265 seconds)
2026-01-23 06:10:50 +0100 <probie> Zemyla: try putting a blank line before what you want to feed to lambdabot
2026-01-23 06:12:44 +0100merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn
2026-01-23 06:15:11 +0100 <chromoblob> Leary: could you elaborate, maybe give an example?
2026-01-23 06:15:51 +0100 <probie> If you send "foo\nbar" it should come through as "<haskellbridge> <Zemyla> foo\n<haskellbridge> bar", so the second line should come through as a separate message, without your username in front and will be picked up by lambdabot or yahb2
2026-01-23 06:16:33 +0100Googulator(~Googulato@2a01-036d-0106-030a-8d41-f550-2a4f-1a91.pool6.digikabel.hu) (Quit: Client closed)
2026-01-23 06:16:44 +0100Googulator(~Googulato@2a01-036d-0106-030a-8d41-f550-2a4f-1a91.pool6.digikabel.hu)
2026-01-23 06:17:25 +0100merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 245 seconds)
2026-01-23 06:18:03 +0100dutchie(~dutchie@user/dutchie) dutchie
2026-01-23 06:22:44 +0100lewisbrown(~user@user/lewisbrown) lewisbrown
2026-01-23 06:25:16 +0100leah2(~leah@vuxu.org) leah2
2026-01-23 06:28:33 +0100merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn
2026-01-23 06:33:25 +0100merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 246 seconds)
2026-01-23 06:36:43 +0100michalz(~michalz@185.246.207.203)
2026-01-23 06:44:22 +0100merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn
2026-01-23 06:45:15 +0100peterbecich(~Thunderbi@71.84.33.135) peterbecich
2026-01-23 06:48:56 +0100merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 240 seconds)
2026-01-23 06:49:46 +0100humasect(~humasect@dyn-192-249-132-90.nexicom.net) humasect
2026-01-23 06:57:25 +0100housemate(~housemate@202.7.248.67) (Quit: https://ineedsomeacidtocalmmedown.space/)
2026-01-23 06:58:54 +0100takuan(~takuan@d8D86B9E9.access.telenet.be)
2026-01-23 07:00:07 +0100merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn
2026-01-23 07:03:25 +0100housemate(~housemate@202.7.248.67) housemate
2026-01-23 07:03:54 +0100Googulator(~Googulato@2a01-036d-0106-030a-8d41-f550-2a4f-1a91.pool6.digikabel.hu) (Quit: Client closed)
2026-01-23 07:04:06 +0100Googulator(~Googulato@2a01-036d-0106-030a-8d41-f550-2a4f-1a91.pool6.digikabel.hu)
2026-01-23 07:05:25 +0100merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 264 seconds)
2026-01-23 07:07:29 +0100weary-traveler(~user@user/user363627) user363627
2026-01-23 07:14:00 +0100notzmv(~umar@user/notzmv) notzmv
2026-01-23 07:15:55 +0100merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn
2026-01-23 07:18:07 +0100jmcantrell(~weechat@user/jmcantrell) (Ping timeout: 240 seconds)
2026-01-23 07:20:35 +0100merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 250 seconds)
2026-01-23 07:22:59 +0100 <Leary> chromoblob: https://gist.github.com/LSLeary/0247b813ad063409d4d09eccc5b077e0
2026-01-23 07:24:11 +0100merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn
2026-01-23 07:25:14 +0100trickard_trickard
2026-01-23 07:28:56 +0100merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 240 seconds)
2026-01-23 07:31:30 +0100 <haskellbridge> <Bowuigi> Related https://github.com/sellout/no-recursion
2026-01-23 07:39:55 +0100merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn
2026-01-23 07:46:34 +0100merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 246 seconds)
2026-01-23 07:47:43 +0100 <probie> recursion-schemes gives you general recursion anyway
2026-01-23 07:49:49 +0100trickard(~trickard@cpe-93-98-47-163.wireline.com.au) (Read error: Connection reset by peer)
2026-01-23 07:50:02 +0100trickard_(~trickard@cpe-93-98-47-163.wireline.com.au)
2026-01-23 07:50:10 +0100 <Leary> "recursion schemes" /= "recursion-schemes"
2026-01-23 07:57:57 +0100merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn
2026-01-23 08:02:50 +0100merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 245 seconds)
2026-01-23 08:06:24 +0100tzh(~tzh@c-76-115-131-146.hsd1.or.comcast.net) (Quit: zzz)
2026-01-23 08:12:54 +0100trickard_(~trickard@cpe-93-98-47-163.wireline.com.au) (Read error: Connection reset by peer)
2026-01-23 08:13:07 +0100trickard_(~trickard@cpe-93-98-47-163.wireline.com.au)
2026-01-23 08:13:44 +0100merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn
2026-01-23 08:18:32 +0100trickard_(~trickard@cpe-93-98-47-163.wireline.com.au) (Read error: Connection reset by peer)
2026-01-23 08:18:39 +0100merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 250 seconds)
2026-01-23 08:21:45 +0100tomboy64(~tomboy64@user/tomboy64) (Ping timeout: 252 seconds)
2026-01-23 08:23:24 +0100trickard_(~trickard@cpe-93-98-47-163.wireline.com.au)
2026-01-23 08:23:28 +0100 <ncf> if you're not allergic to general recursion you can do the exact same thing using just one data type and no impredicative encodings https://gist.github.com/ncfavier/d42d077745c73dfb2e2c58592b1cd7e1
2026-01-23 08:24:04 +0100tomboy64(~tomboy64@user/tomboy64) tomboy64
2026-01-23 08:24:51 +0100 <ncf> (note that general recursion is used rather controlledly here, in `fold` and `unfold`, so you could make those abstract and pretend they are primitives)
2026-01-23 08:25:07 +0100merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn
2026-01-23 08:29:58 +0100merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 246 seconds)
2026-01-23 08:40:55 +0100merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn
2026-01-23 08:44:06 +0100danza(~danza@user/danza) danza
2026-01-23 08:45:54 +0100merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 256 seconds)
2026-01-23 08:48:32 +0100peterbecich(~Thunderbi@71.84.33.135) (Ping timeout: 240 seconds)
2026-01-23 08:53:02 +0100humasect(~humasect@dyn-192-249-132-90.nexicom.net) (Quit: Leaving...)
2026-01-23 08:56:21 +0100Googulator(~Googulato@2a01-036d-0106-030a-8d41-f550-2a4f-1a91.pool6.digikabel.hu) (Ping timeout: 272 seconds)
2026-01-23 08:56:42 +0100merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn
2026-01-23 08:56:46 +0100sord937(~sord937@gateway/tor-sasl/sord937) sord937
2026-01-23 09:01:27 +0100merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 244 seconds)
2026-01-23 09:03:40 +0100oskarw(~user@user/oskarw) oskarw
2026-01-23 09:06:01 +0100xff0x(~xff0x@fsb6a9491c.tkyc517.ap.nuro.jp) (Ping timeout: 246 seconds)
2026-01-23 09:08:04 +0100xff0x(~xff0x@fsb6a9491c.tkyc517.ap.nuro.jp)
2026-01-23 09:08:39 +0100merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn
2026-01-23 09:10:49 +0100FANTOM(~fantom@87.75.185.177) (Read error: Connection reset by peer)
2026-01-23 09:13:20 +0100merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 244 seconds)
2026-01-23 09:21:24 +0100Lycurgus(~juan@user/Lycurgus) Lycurgus
2026-01-23 09:24:26 +0100merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn
2026-01-23 09:31:13 +0100merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 264 seconds)
2026-01-23 09:35:27 +0100merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn
2026-01-23 09:40:57 +0100AlexZenon(~alzenon@94.233.241.51) (Ping timeout: 252 seconds)
2026-01-23 09:42:04 +0100 <Leary> ncf: That fails to encapsulate general recursion since it's easily recoverable in the form of `fix :: (a -> a) -> a`, though perhaps if we also disallowed bottoms that wouldn't be the case.
2026-01-23 09:42:25 +0100AlexNoo(~AlexNoo@94.233.241.51) (Ping timeout: 246 seconds)
2026-01-23 09:42:36 +0100Alex_delenda_est(~al_test@94.233.241.51) (Ping timeout: 252 seconds)
2026-01-23 09:43:43 +0100trickard_trickard
2026-01-23 09:50:04 +0100 <gentauro> jackdk: thx for links and info. It's a bit sad that `eXchange` lost all their IP when they went bankrupt and now the few surviving videos look like they were recorded with a toaster :'(
2026-01-23 09:50:34 +0100 <jackdk> Yeah it's such a shame. Though I don't think that particular talk ever had a good recording
2026-01-23 09:50:55 +0100 <gentauro> I actually tried to "re-spawn" the hole concept of `eXchange` again as they were bought by Trifork. I made slides and stuff and provided all the "nice" names
2026-01-23 09:51:16 +0100 <gentauro> then suddently, you see all those names at "GOTO Conferences" (yeah Trifork also own them)
2026-01-23 09:51:46 +0100 <int-e> I know it was a typo, but "hole concept" is pretty accurate (think "memory hole")
2026-01-23 09:51:48 +0100 <gentauro> never EVER trust `corpos`. It's just a matter of if, but when, they will screw you :(
2026-01-23 09:53:04 +0100haritz(~hrtz@user/haritz) (Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in)
2026-01-23 09:53:08 +0100 <gentauro> the good thing? At least they bring "the names" to mainstream -> https://www.youtube.com/watch?v=lg0RYLlmjJM
2026-01-23 09:53:13 +0100 <gentauro> ;)
2026-01-23 09:53:54 +0100 <gentauro> and good old Kris -> https://www.youtube.com/watch?v=SOz66dcsuT8
2026-01-23 09:54:54 +0100 <gentauro> Elm Evan -> https://www.youtube.com/watch?v=TklYhw0Kl58 (btw, does anybody know if that `lang` is `dead`?)
2026-01-23 10:01:16 +0100sord937(~sord937@gateway/tor-sasl/sord937) (Ping timeout: 252 seconds)
2026-01-23 10:02:18 +0100sord937(~sord937@gateway/tor-sasl/sord937) sord937
2026-01-23 10:02:56 +0100acidjnk(~acidjnk@p200300d6e7171963e9342c1b23054bda.dip0.t-ipconnect.de) (Ping timeout: 244 seconds)
2026-01-23 10:16:08 +0100Sgeo(~Sgeo@user/sgeo) (Read error: Connection reset by peer)
2026-01-23 10:19:22 +0100xff0x(~xff0x@fsb6a9491c.tkyc517.ap.nuro.jp) (Ping timeout: 244 seconds)
2026-01-23 10:21:17 +0100xff0x(~xff0x@fsb6a9491c.tkyc517.ap.nuro.jp)
2026-01-23 10:23:48 +0100housemate(~housemate@202.7.248.67) (Remote host closed the connection)
2026-01-23 10:24:40 +0100housemate(~housemate@202.7.248.67) housemate
2026-01-23 10:25:19 +0100housemate(~housemate@202.7.248.67) (Remote host closed the connection)
2026-01-23 10:25:25 +0100Googulator(~Googulato@team.broadbit.hu)
2026-01-23 10:25:38 +0100chele(~chele@user/chele) chele
2026-01-23 10:26:31 +0100housemate(~housemate@202.7.248.67) housemate
2026-01-23 10:26:58 +0100machinedgod(~machinedg@d75-159-126-101.abhsia.telus.net) machinedgod
2026-01-23 10:27:17 +0100housemate(~housemate@202.7.248.67) (Max SendQ exceeded)
2026-01-23 10:27:18 +0100skum(~skum@user/skum) skum
2026-01-23 10:29:30 +0100housemate(~housemate@202.7.248.67) housemate
2026-01-23 10:30:01 +0100CiaoSen(~Jura@2a02:8071:64e1:da0:5a47:caff:fe78:33db) CiaoSen
2026-01-23 10:30:11 +0100housemate(~housemate@202.7.248.67) (Max SendQ exceeded)
2026-01-23 10:30:37 +0100xff0x(~xff0x@fsb6a9491c.tkyc517.ap.nuro.jp) (Ping timeout: 264 seconds)
2026-01-23 10:30:41 +0100housemate(~housemate@202.7.248.67) housemate
2026-01-23 10:31:09 +0100housemate(~housemate@202.7.248.67) (Remote host closed the connection)
2026-01-23 10:31:38 +0100housemate(~housemate@202.7.248.67) housemate
2026-01-23 10:31:43 +0100housemate(~housemate@202.7.248.67) (Remote host closed the connection)
2026-01-23 10:32:29 +0100xff0x(~xff0x@fsb6a9491c.tkyc517.ap.nuro.jp)
2026-01-23 10:33:37 +0100 <bwe> How can I let wai / warp update an internal data cache regularly by querying some database (no, I don’t mean response cache)?
2026-01-23 10:33:41 +0100XZDX(~xzdx@2601:404:ce00:b795:214:51ff:fe83:9855)
2026-01-23 10:35:33 +0100XZDX(~xzdx@2601:404:ce00:b795:214:51ff:fe83:9855) (Changing host)
2026-01-23 10:35:33 +0100XZDX(~xzdx@user/XZDX) XZDX
2026-01-23 10:48:07 +0100Googulator(~Googulato@team.broadbit.hu) (Quit: Client closed)
2026-01-23 10:50:47 +0100vanishingideal(~vanishing@user/vanishingideal) vanishingideal
2026-01-23 11:04:00 +0100fp(~Thunderbi@2001-14ba-6e24-3000--198.rev.dnainternet.fi) (Ping timeout: 252 seconds)
2026-01-23 11:05:10 +0100 <danza> are you sure that is the right level of abstraction? Wai/warp sound too close to the server for a cache that has to query a database
2026-01-23 11:05:50 +0100xff0x(~xff0x@fsb6a9491c.tkyc517.ap.nuro.jp) (Ping timeout: 265 seconds)
2026-01-23 11:06:32 +0100__monty__(~toonn@user/toonn) toonn
2026-01-23 11:07:29 +0100 <[exa]> bwe: can you be more specific on "internal data cache"? (does wai have a cache?)
2026-01-23 11:12:56 +0100vanishingideal(~vanishing@user/vanishingideal) (Ping timeout: 240 seconds)
2026-01-23 11:13:49 +0100 <danza> data-based contents would be provided at application level, but it's tricky to cache because database contents can change
2026-01-23 11:14:20 +0100trickard(~trickard@cpe-93-98-47-163.wireline.com.au) (Read error: Connection reset by peer)
2026-01-23 11:14:32 +0100trickard(~trickard@cpe-93-98-47-163.wireline.com.au)
2026-01-23 11:17:09 +0100ljdarj(~Thunderbi@user/ljdarj) ljdarj
2026-01-23 11:25:39 +0100Googulator(~Googulato@team.broadbit.hu)
2026-01-23 11:28:03 +0100merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) (Read error: Connection reset by peer)
2026-01-23 11:28:10 +0100merijn(~merijn@77.242.116.146) merijn
2026-01-23 11:30:55 +0100hellwolf(~user@4cde-2438-8978-87b1-0f00-4d40-07d0-2001.sta.estpak.ee) (Ping timeout: 264 seconds)
2026-01-23 11:30:59 +0100Square2(~Square@user/square) Square
2026-01-23 11:34:47 +0100 <bwe> [exa]: I currently load data when the web server starts. It hands over the data to hyperbole web framework in a Reader context through Effectful. What I want is that it loads it all 3 minutes for example without reloading the web server altogether.
2026-01-23 11:35:52 +0100Googulator23(~Googulato@team.broadbit.hu)
2026-01-23 11:35:58 +0100 <[exa]> bwe: you can have a MVar in the Reader that points to data, and replace it every now and then from a completely independent thread?
2026-01-23 11:35:59 +0100 <bwe> danza: So, the internal data cache actually lies in the hyperbole framework. But I pull it only in on start of warp.
2026-01-23 11:36:34 +0100 <[exa]> (I'm not very sure how hyperbole works but if you use Reader, pushing in the MVar shouldn't be a big issue.)
2026-01-23 11:37:16 +0100 <bwe> [exa]: Well, if I get you right, that is similar to what I thought. "How can I update some thing in a different thread from another (that just sleeps between updates)?"
2026-01-23 11:38:43 +0100 <bwe> danza: I am quite tolerant for outdated database states within a range of up to 3 minutes (update time of my internal cache).
2026-01-23 11:39:00 +0100 <[exa]> bwe: yeah MVars are great for that, loading them doesn't cost anything and you can atomically flip to the new state
2026-01-23 11:39:45 +0100Googulator(~Googulato@team.broadbit.hu) (Ping timeout: 272 seconds)
2026-01-23 11:40:33 +0100 <danza> but they should have one MVar per query? Anyway yes, sounds like something better solved in hyperbole
2026-01-23 11:41:14 +0100hellwolf(~user@e7d0-28a4-0ea3-c496-0f00-4d40-07d0-2001.sta.estpak.ee) hellwolf
2026-01-23 11:46:35 +0100fp(~Thunderbi@2001:708:20:1406::10c5) fp
2026-01-23 11:47:20 +0100 <bwe> ...and I thought data stored in Reader doesn't change (once loaded).
2026-01-23 11:49:11 +0100 <bwe> Then MVar is nothing but a (changeable) State across different threads, does that mean different binaries? How do they find them each other, then?
2026-01-23 11:50:48 +0100 <__monty__> Threads don't imply different binaries. They don't even imply different processes. Rather the reverse.
2026-01-23 11:54:04 +0100 <mauke> :t forkIO
2026-01-23 11:54:05 +0100 <lambdabot> error: [GHC-88464] Variable not in scope: forkIO
2026-01-23 11:54:18 +0100 <[exa]> bwe: yeah technically the "variable" reference doesn't change, but you're allowed to rewrite what's it pointing to
2026-01-23 11:57:02 +0100 <bwe> __monty__: So, when I start the web server, I need to fork from that the runner that updates the MVar. That would work while different binary doesn't, right?
2026-01-23 11:57:11 +0100trickard(~trickard@cpe-93-98-47-163.wireline.com.au) (Read error: Connection reset by peer)
2026-01-23 11:57:20 +0100XZDX(~xzdx@user/XZDX) (Remote host closed the connection)
2026-01-23 11:57:25 +0100trickard_(~trickard@cpe-93-98-47-163.wireline.com.au)
2026-01-23 11:59:39 +0100thenightmail(~thenightm@user/thenightmail) (Ping timeout: 260 seconds)
2026-01-23 12:00:04 +0100thenightmail(~thenightm@user/thenightmail) thenightmail
2026-01-23 12:00:20 +0100oskarw(~user@user/oskarw) (Remote host closed the connection)
2026-01-23 12:01:05 +0100lantti(~lantti@xcalibur.cc.tut.fi)
2026-01-23 12:01:43 +0100oskarw(~user@user/oskarw) oskarw
2026-01-23 12:04:01 +0100 <__monty__> I'm not sure. mauke seems to suggest using forkIO.
2026-01-23 12:04:48 +0100vanishingideal(~vanishing@user/vanishingideal) vanishingideal
2026-01-23 12:06:19 +0100 <mauke> if we're just updating a data structure that someone else reads from and no other interaction, wouldn't an IORef suffice?
2026-01-23 12:07:39 +0100 <mauke> https://hackage-content.haskell.org/package/base-4.22.0.0/docs/Data-IORef.html#v:atomicModifyIORef
2026-01-23 12:08:38 +0100 <__monty__> Does an MVar have that much more overhead that the footgun factor is worth it?
2026-01-23 12:08:55 +0100 <tomsmeding> an MVar definitely has much more overhead than an IORef
2026-01-23 12:09:04 +0100 <mauke> footgun how?
2026-01-23 12:09:19 +0100 <tomsmeding> it's a lock with an explicit queue attached (a list of threads waiting to take the lock) for fairness
2026-01-23 12:09:33 +0100 <tomsmeding> atomicModifyIORef is little more than a single CPU instruction (compare-and-swap)
2026-01-23 12:09:49 +0100 <tomsmeding> whether this is important in the application depends on how often you do this, of course
2026-01-23 12:13:15 +0100 <tomsmeding> in return for the overhead, an MVar gives you 1. fairness (if you're blocking on the MVar and no one holds the MVar indefinitely, you're guaranteed to get it eventually), 2. the ability to do IO while holding the lock
2026-01-23 12:13:27 +0100housemate(~housemate@2405:6e00:2457:9d18:a3e8:cd50:91c3:2f91) housemate
2026-01-23 12:15:59 +0100 <tomsmeding> also 3. an MVar can also function as a one-place channel instead of a lock
2026-01-23 12:16:25 +0100merijn(~merijn@77.242.116.146) (Ping timeout: 246 seconds)
2026-01-23 12:18:55 +0100 <danza> well that sounds saner to me for the goal
2026-01-23 12:27:28 +0100Square2(~Square@user/square) (Ping timeout: 256 seconds)
2026-01-23 12:28:06 +0100housemate(~housemate@2405:6e00:2457:9d18:a3e8:cd50:91c3:2f91) (Quit: https://ineedsomeacidtocalmmedown.space/)
2026-01-23 12:29:21 +0100 <__monty__> mauke: The footgun is thinking you'll be able to just add another IORef later and not run into trouble.
2026-01-23 12:30:26 +0100 <mauke> applies to MVar, too
2026-01-23 12:30:30 +0100merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn
2026-01-23 12:31:45 +0100 <__monty__> So the doc suggesting MVars instead is misleading?
2026-01-23 12:32:46 +0100 <mauke> well, it only talks about atomicity
2026-01-23 12:32:56 +0100 <mauke> with MVars you can deadlock instead
2026-01-23 12:33:06 +0100 <int-e> "Extending the atomicity to multiple IORefs is problematic, so it is recommended that if you need to do anything more complicated then using MVar instead is a good idea."
2026-01-23 12:33:19 +0100 <int-e> If that's what you mean I don't know how it's misleading.
2026-01-23 12:34:47 +0100Inline(~User@2001-4dd7-bc56-0-bf4e-84aa-8c9c-590c.ipv6dyn.netcologne.de) (Quit: KVIrc 5.2.6 Quasar http://www.kvirc.net/)
2026-01-23 12:34:48 +0100danz20169(~danza@user/danza) danza
2026-01-23 12:35:37 +0100 <__monty__> Well, it suggests you can extend atomicity across multiple, no? So if you can't do that easily without deadlocking it's not a great suggestion.
2026-01-23 12:36:31 +0100 <Axman6> you just have to be careful about the order you access things
2026-01-23 12:36:36 +0100 <int-e> You can't atomically update two IORefs at the same time.
2026-01-23 12:36:43 +0100trickard_trickard
2026-01-23 12:36:44 +0100 <Axman6> IIRC MVar has a consistent Ord instance?
2026-01-23 12:37:06 +0100danza(~danza@user/danza) (Ping timeout: 256 seconds)
2026-01-23 12:37:25 +0100merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 255 seconds)
2026-01-23 12:37:42 +0100 <Axman6> IORefs with atomicModifyIORef are amazing, if you can store all your state in pure data structures that can always be changed without doing any other IO. if you can't guarantee those properties, other options are much safer
2026-01-23 12:37:47 +0100 <int-e> (But you can have a single IORef that stores a tuple or a record.)
2026-01-23 12:39:04 +0100 <Axman6> I've been reading a lot of the Cardano code recently, and they make a lot of use of STM, as well as pure data structures.
2026-01-23 12:39:05 +0100 <mauke> or a Map
2026-01-23 12:39:57 +0100 <Axman6> they can store an arbitrarily complicated record too, and aMIOref can be used to update as much or as little of that structure as you like
2026-01-23 12:40:19 +0100 <mauke> I had a server that would answer client queries from a central data structure (a Map stored in an IORef)
2026-01-23 12:40:41 +0100 <mauke> there was a writer thread that would occasionally update the structure by just overwriting the Map
2026-01-23 12:41:08 +0100 <mauke> worked great
2026-01-23 12:41:34 +0100 <Axman6> I have also done that - it needed to serve images of some live-ish data, and generating the images was pretty slow, so with each new piece of data it'd just make new PNGs and update the map in the IORef. Meant all the HTTP requests were instant
2026-01-23 12:43:10 +0100 <danz20169> seems a solution suited to server-side data vis
2026-01-23 12:44:39 +0100 <danz20169> did you use any library to encode PNGs as types?
2026-01-23 12:45:34 +0100 <danz20169> maybe just passed them as black boxes
2026-01-23 12:48:20 +0100merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn
2026-01-23 12:49:47 +0100merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) (Read error: Connection reset by peer)
2026-01-23 12:50:41 +0100Googulator23(~Googulato@team.broadbit.hu) (Ping timeout: 272 seconds)
2026-01-23 12:51:27 +0100 <tomsmeding> __monty__: while yes, adding another IORef later means you can't update both in the same atomic transaction, I'm not sure what part of the API would lead one to assume that you can
2026-01-23 12:52:03 +0100 <tomsmeding> if anything, having to order locks to avoid deadlock is a more insidious risk that you may not see coming if you haven't studied concurrent programming
2026-01-23 12:52:41 +0100 <__monty__> You may be right.
2026-01-23 12:53:01 +0100 <tomsmeding> (for completeness: you have two locks, A and B, and two threads, 1 and 2. 1 locks A and then B, and 2 locks B and then A. If the two executions interleave, 1 has A locked and 2 has B locked and they both wait on the other, indefinitely)
2026-01-23 12:53:20 +0100merijn(~merijn@77.242.116.146) merijn
2026-01-23 12:53:23 +0100 <tomsmeding> (if you only ever lock such locks in a particular global order, this problem cannot arise)
2026-01-23 12:53:26 +0100 <int-e> You can perhaps criticize the IORef docs for not mentioning STM, but the reason for that is probably historical, and you'll find out about STM when you read the MVar docs.
2026-01-23 12:56:14 +0100 <tomsmeding> and if you are worried about performance implications of using an MVar over an IORef, you should also be worried about STM, as it similar (?) overhead, and also has starvation issues if you have very long and also very short transactions that update the same TVars
2026-01-23 12:56:28 +0100 <tomsmeding> *as it has similar
2026-01-23 12:56:51 +0100fp1(~Thunderbi@2001:708:150:10::9d7e) fp
2026-01-23 12:57:16 +0100 <int-e> Do we have any canonical STM horror story (along the lines of "it worked great until we ran it in production with 50 simultaneous threads and then it spent 90% of its time retrying STM transactions"?)
2026-01-23 12:57:22 +0100 <tomsmeding> concurrent programming: correct, fast, convenient; pick 2
2026-01-23 12:57:27 +0100 <ncf> Leary: i didn't mean to encapsulate general recursion tbh, only to point out that the clarity of expressing things in terms of (co)algebras needn't come at the price of general recursion
2026-01-23 12:57:29 +0100fp(~Thunderbi@2001:708:20:1406::10c5) (Ping timeout: 265 seconds)
2026-01-23 12:57:29 +0100fp1fp
2026-01-23 12:57:54 +0100 <tomsmeding> int-e: I'm not aware of any, I'm an academic
2026-01-23 13:00:51 +0100 <tomsmeding> Axman6: MVar doesn't implement Ord, only Eq
2026-01-23 13:01:37 +0100Googulator23(~Googulato@team.broadbit.hu)
2026-01-23 13:03:09 +0100 <tomsmeding> (you may be thinking of ForeignPtr, which does implement Ord)
2026-01-23 13:05:33 +0100comonad(~comonad@p200300d02722ae00dce4ce9451b59974.dip0.t-ipconnect.de) (Ping timeout: 260 seconds)
2026-01-23 13:10:54 +0100Googulator25(~Googulato@team.broadbit.hu)
2026-01-23 13:10:54 +0100Googulator23(~Googulato@team.broadbit.hu) (Quit: Client closed)
2026-01-23 13:17:59 +0100 <merijn> int-e: Almost surely
2026-01-23 13:18:10 +0100 <merijn> int-e: Bad STM design can easily cause that
2026-01-23 13:20:35 +0100 <merijn> tomsmeding: MVar doesn't have to ever lock and queue if you don't want to, though
2026-01-23 13:25:13 +0100 <tomsmeding> merijn: what do you mean?
2026-01-23 13:25:28 +0100hakutaku(~textual@chen.yukari.eu.org) (Quit: My MacBook has gone to sleep. ZZZzzz…)
2026-01-23 13:26:02 +0100 <bwe> Axman6, mauke: that's exactly what I want to do, I know when I've got new data and only then want to update the IORef / MVar. -- So if I only want to swap something out, I'd be fine with an IORef?
2026-01-23 13:26:18 +0100xff0x(~xff0x@2405:6580:b080:900:3b58:3b23:6c7:a174)
2026-01-23 13:26:37 +0100 <tomsmeding> bwe: if the type of atomicModifyIORef' (mind the ') is good enough for you, it's almost guaranteed to be the fastest option
2026-01-23 13:26:38 +0100 <bwe> tomsmeding: how would we categorize MVar, TVar, STM, IORef into two out of three of: correct, fast, convenient?
2026-01-23 13:27:31 +0100 <tomsmeding> bwe: it's more how you use them, although neither MVar nor TVar are particularly fast (STM is just the framework around TVar so not a separate thing)
2026-01-23 13:27:49 +0100 <tomsmeding> IORefs are plenty convenient if all you need is atomicModifyIORef', but they are rather limited otherwise
2026-01-23 13:28:28 +0100 <tomsmeding> TVar is convenient and correct across the board (programming with STM is great!), but depending on your application's behaviour it may not be very fast
2026-01-23 13:31:20 +0100 <tomsmeding> (you can get correct + fast + convenient if you never need to communicate between threads! Read-only shared data works very well ;p)
2026-01-23 13:31:31 +0100 <bwe> tomsmeding: I simply need to update a state from db. Effectively swapping the old data for the new data. I am not sure how can I tell right now whether the type of atomicModifyIORef' fits my use case, though.
2026-01-23 13:31:53 +0100 <tomsmeding> bwe: it kind of sounds like atomicModifyIORef' is good enough; if it isn't, come back
2026-01-23 13:36:14 +0100DetourNe-(~DetourNet@user/DetourNetworkUK) DetourNetworkUK
2026-01-23 13:36:47 +0100DetourNetworkUK(~DetourNet@user/DetourNetworkUK) (Read error: Connection reset by peer)
2026-01-23 13:38:11 +0100 <bwe> tomsmeding: ok, thanks.
2026-01-23 13:38:31 +0100DetourNe-DetourNetworkUK
2026-01-23 13:39:25 +0100fp(~Thunderbi@2001:708:150:10::9d7e) (Ping timeout: 244 seconds)
2026-01-23 13:39:37 +0100danz20169(~danza@user/danza) (Quit: got to go)
2026-01-23 13:42:00 +0100fp(~Thunderbi@2001:708:150:10::9d7e) fp
2026-01-23 13:47:25 +0100vanishingideal(~vanishing@user/vanishingideal) (Ping timeout: 264 seconds)
2026-01-23 13:52:35 +0100CiaoSen(~Jura@2a02:8071:64e1:da0:5a47:caff:fe78:33db) (Ping timeout: 265 seconds)
2026-01-23 13:53:51 +0100 <merijn> tomsmeding: readMVar is non blocking on full MVars
2026-01-23 13:54:20 +0100 <merijn> bwe: tbh, "not very fast" here still means "pretty goddamn fast"
2026-01-23 13:55:13 +0100 <tomsmeding> merijn: as I said: if you only ever need to read, yes, life is easy :p
2026-01-23 13:55:25 +0100 <merijn> If your update frequencies is measures in "once every few seconds" (or less frequent) the performance difference between any of the solutions is essentially irrelevant
2026-01-23 13:55:31 +0100 <tomsmeding> ^
2026-01-23 13:55:43 +0100 <merijn> if it's sub-second then it *might* matter
2026-01-23 13:56:24 +0100 <merijn> once you're planning to update every N milliseconds, that's when I'd consider thinking about performance implications
2026-01-23 13:56:30 +0100 <tomsmeding> I recommended atomicModifyIORef' more because it does what it does well, and doesn't suggest it can do any more than it does :p
2026-01-23 14:00:41 +0100img(~img@user/img) (Quit: ZNC 1.10.1 - https://znc.in)
2026-01-23 14:01:55 +0100img(~img@user/img) img
2026-01-23 14:07:35 +0100karenw(~karenw@user/karenw) karenw
2026-01-23 14:10:39 +0100Googulator63(~Googulato@team.broadbit.hu)
2026-01-23 14:14:17 +0100Googulator25(~Googulato@team.broadbit.hu) (Ping timeout: 272 seconds)
2026-01-23 14:19:04 +0100bggd_(~bgg@2a01:e0a:fd5:f510:5241:8daa:4da4:a780) (Ping timeout: 260 seconds)
2026-01-23 14:21:31 +0100 <haskellbridge> <Zemyla> So you need a newtype to fold over both lists. @let newtype Z a b = Z { runZ :: a -> (Z a b -> b) -> b } @let zipF :: [a] -> [b] -> [(a, b)]; zipF xs ys = foldr (\a ak bk -> runZ bk a ak) (const []) xs $ foldr (\b bk -> Z $ \a ak -> (a, b):ak bk) (Z $ _ _ -> []) ys
2026-01-23 14:21:46 +0100 <haskellbridge> <Zemyla> I used newlines, and it still didn't work. D:
2026-01-23 14:27:05 +0100trickard(~trickard@cpe-93-98-47-163.wireline.com.au) (Read error: Connection reset by peer)
2026-01-23 14:27:19 +0100trickard_(~trickard@cpe-93-98-47-163.wireline.com.au)
2026-01-23 14:28:54 +0100qqq(~qqq@185.54.21.105)
2026-01-23 14:30:57 +0100Zemy_(~Zemy@2600:100c:b0a7:500d:4426:a6ff:feb6:d198)
2026-01-23 14:30:57 +0100Zemy(~Zemy@72.178.108.235) (Read error: Connection reset by peer)
2026-01-23 14:31:54 +0100Zemy(~Zemy@72.178.108.235)
2026-01-23 14:35:36 +0100Zemy_(~Zemy@2600:100c:b0a7:500d:4426:a6ff:feb6:d198) (Ping timeout: 265 seconds)
2026-01-23 14:37:46 +0100 <haskellbridge> <geekosaur> .
2026-01-23 14:37:46 +0100 <haskellbridge> @botsnack
2026-01-23 14:38:11 +0100 <haskellbridge> <geekosaur> got the newline, inserted a space as well ☹️
2026-01-23 14:38:14 +0100wennefer0(~wennefer0@user/wennefer0) (Read error: Connection reset by peer)
2026-01-23 14:38:49 +0100 <geekosaur> also you used too many lines, it would have been pastebinned
2026-01-23 14:38:57 +0100 <geekosaur> (if the newlines had gone through)
2026-01-23 14:40:48 +0100trickard_(~trickard@cpe-93-98-47-163.wireline.com.au) (Read error: Connection reset by peer)
2026-01-23 14:41:01 +0100trickard_(~trickard@cpe-93-98-47-163.wireline.com.au)
2026-01-23 14:41:44 +0100machinedgod(~machinedg@d75-159-126-101.abhsia.telus.net) (Ping timeout: 240 seconds)
2026-01-23 14:44:08 +0100comonad(~comonad@p200300d02722ae00dce4ce9451b59974.dip0.t-ipconnect.de)
2026-01-23 14:51:20 +0100 <haskellbridge> <Zemyla> But what this does is fold the lists into a pair of coroutines which interleave.
2026-01-23 14:56:04 +0100Zemy_(~Zemy@2600:100c:b0a7:500d:6465:32ff:febf:6476)
2026-01-23 14:58:18 +0100Zemy(~Zemy@72.178.108.235) (Ping timeout: 252 seconds)
2026-01-23 15:02:25 +0100fp(~Thunderbi@2001:708:150:10::9d7e) (Ping timeout: 245 seconds)
2026-01-23 15:03:11 +0100hakutaku(~textual@chen.yukari.eu.org)
2026-01-23 15:04:22 +0100fp(~Thunderbi@2001:708:20:1406::1370) fp
2026-01-23 15:09:24 +0100Zemy(~Zemy@mobile-107-80-206-40.mycingular.net)
2026-01-23 15:12:09 +0100Zemy_(~Zemy@2600:100c:b0a7:500d:6465:32ff:febf:6476) (Ping timeout: 260 seconds)
2026-01-23 15:12:25 +0100Zemy_(~Zemy@mobile-107-80-206-40.mycingular.net)
2026-01-23 15:15:57 +0100Zemy(~Zemy@mobile-107-80-206-40.mycingular.net) (Ping timeout: 250 seconds)
2026-01-23 15:18:27 +0100Zemy(~Zemy@mobile-107-80-206-40.mycingular.net)
2026-01-23 15:21:09 +0100Zemy_(~Zemy@mobile-107-80-206-40.mycingular.net) (Ping timeout: 250 seconds)
2026-01-23 15:22:29 +0100Zemy_(~Zemy@mobile-107-80-206-40.mycingular.net)
2026-01-23 15:22:37 +0100Core6390(~Zemy@2600:100c:b0a7:500d:444d:5bff:fe79:c99d)
2026-01-23 15:23:17 +0100Core8830(~Zemy@12.50.228.210)
2026-01-23 15:25:03 +0100Zemy(~Zemy@mobile-107-80-206-40.mycingular.net) (Ping timeout: 250 seconds)
2026-01-23 15:26:09 +0100ZLima12(~zlima12@user/meow/ZLima12) (Ping timeout: 260 seconds)
2026-01-23 15:26:49 +0100Core6390(~Zemy@2600:100c:b0a7:500d:444d:5bff:fe79:c99d) (Ping timeout: 246 seconds)
2026-01-23 15:26:49 +0100Zemy_(~Zemy@mobile-107-80-206-40.mycingular.net) (Ping timeout: 246 seconds)
2026-01-23 15:28:48 +0100ZLima12(~zlima12@user/meow/ZLima12) ZLima12
2026-01-23 15:32:13 +0100Core8830(~Zemy@12.50.228.210) (Read error: Connection reset by peer)
2026-01-23 15:32:23 +0100Zemy(~Zemy@2600:100c:b0a7:500d:9c2b:5aff:fe6b:6dd6)
2026-01-23 15:32:52 +0100Zemy_(~Zemy@syn-192-198-252-043.biz.spectrum.com)
2026-01-23 15:34:51 +0100Zemy(~Zemy@2600:100c:b0a7:500d:9c2b:5aff:fe6b:6dd6) (Read error: Connection reset by peer)
2026-01-23 15:35:02 +0100Zemy(~Zemy@2600:100c:b0a7:500d:9051:50ff:fef4:1dd3)
2026-01-23 15:36:35 +0100Zemy_(~Zemy@syn-192-198-252-043.biz.spectrum.com) (Read error: Connection reset by peer)
2026-01-23 15:37:01 +0100Zemy_(~Zemy@syn-192-198-252-043.biz.spectrum.com)
2026-01-23 15:39:33 +0100Zemy(~Zemy@2600:100c:b0a7:500d:9051:50ff:fef4:1dd3) (Ping timeout: 252 seconds)
2026-01-23 15:40:16 +0100Zemy_(~Zemy@syn-192-198-252-043.biz.spectrum.com) (Read error: Connection reset by peer)
2026-01-23 15:40:22 +0100Zemy(~Zemy@2600:100c:b0a7:500d:c49:b7ff:fe30:b590)
2026-01-23 15:40:52 +0100Zemy_(~Zemy@12.50.228.210)
2026-01-23 15:41:43 +0100karenw(~karenw@user/karenw) (Quit: Deep into that darkness peering...)
2026-01-23 15:43:51 +0100Zemy(~Zemy@2600:100c:b0a7:500d:c49:b7ff:fe30:b590) (Read error: Connection reset by peer)
2026-01-23 15:44:24 +0100Zemy(~Zemy@2600:100c:b0a7:500d:e02b:53ff:fe18:58a7)
2026-01-23 15:44:24 +0100Zemy_(~Zemy@12.50.228.210) (Read error: Connection reset by peer)
2026-01-23 15:44:43 +0100fp(~Thunderbi@2001:708:20:1406::1370) (Ping timeout: 264 seconds)
2026-01-23 15:44:47 +0100pavonia(~user@user/siracusa) (Quit: Bye!)
2026-01-23 15:44:59 +0100Zemy_(~Zemy@12.50.228.210)
2026-01-23 15:45:13 +0100nek0(~nek0@user/nek0) (Quit: The Lounge - https://thelounge.chat)
2026-01-23 15:46:19 +0100Core7076(~Zemy@mobile-107-80-206-16.mycingular.net)
2026-01-23 15:48:54 +0100Zemy(~Zemy@2600:100c:b0a7:500d:e02b:53ff:fe18:58a7) (Ping timeout: 260 seconds)
2026-01-23 15:49:33 +0100Zemy_(~Zemy@12.50.228.210) (Ping timeout: 265 seconds)
2026-01-23 15:51:05 +0100nek0(~nek0@user/nek0) nek0
2026-01-23 15:55:57 +0100st_aldini(~Thunderbi@136.48.46.187) st_aldini
2026-01-23 15:56:25 +0100Zemy(~Zemy@2600:100c:b0a7:500d:a4b2:14ff:fe15:3e1e)
2026-01-23 15:56:39 +0100machinedgod(~machinedg@d75-159-126-101.abhsia.telus.net) machinedgod
2026-01-23 15:57:47 +0100danza(~danza@user/danza) danza
2026-01-23 16:00:40 +0100Core7076(~Zemy@mobile-107-80-206-16.mycingular.net) (Ping timeout: 265 seconds)
2026-01-23 16:04:40 +0100Zemy_(~Zemy@72.178.108.235)
2026-01-23 16:04:43 +0100Sgeo(~Sgeo@user/sgeo) Sgeo
2026-01-23 16:04:56 +0100gmg(~user@user/gehmehgeh) (Remote host closed the connection)
2026-01-23 16:05:40 +0100gmg(~user@user/gehmehgeh) gehmehgeh
2026-01-23 16:08:09 +0100Zemy(~Zemy@2600:100c:b0a7:500d:a4b2:14ff:fe15:3e1e) (Ping timeout: 260 seconds)
2026-01-23 16:17:29 +0100Zemy(~Zemy@2600:100c:b0a7:500d:40a4:72ff:fef0:aeb0)
2026-01-23 16:17:43 +0100Zemy_(~Zemy@72.178.108.235) (Read error: Connection reset by peer)
2026-01-23 16:18:08 +0100Googulator63Googulator
2026-01-23 16:18:23 +0100Zemy_(~Zemy@72.178.108.235)
2026-01-23 16:21:46 +0100Zemy(~Zemy@2600:100c:b0a7:500d:40a4:72ff:fef0:aeb0) (Ping timeout: 246 seconds)
2026-01-23 16:25:15 +0100hakutaku(~textual@chen.yukari.eu.org) (Quit: My MacBook has gone to sleep. ZZZzzz…)
2026-01-23 16:28:06 +0100hakutaku(~textual@chen.yukari.eu.org)
2026-01-23 16:35:27 +0100danz33286(~danza@user/danza) danza
2026-01-23 16:35:58 +0100absence(torgeihe@hildring.pvv.ntnu.no) absence
2026-01-23 16:37:44 +0100Zemy(~Zemy@2600:100c:b0a7:500d:1c6f:88ff:fed8:ebd3)
2026-01-23 16:37:45 +0100Zemy_(~Zemy@72.178.108.235) (Read error: Connection reset by peer)
2026-01-23 16:37:54 +0100danza(~danza@user/danza) (Ping timeout: 260 seconds)
2026-01-23 16:38:19 +0100Zemy_(~Zemy@72.178.108.235)
2026-01-23 16:42:04 +0100Zemy(~Zemy@2600:100c:b0a7:500d:1c6f:88ff:fed8:ebd3) (Ping timeout: 246 seconds)
2026-01-23 16:46:48 +0100sord937(~sord937@gateway/tor-sasl/sord937) (Ping timeout: 252 seconds)
2026-01-23 16:47:37 +0100sord937(~sord937@gateway/tor-sasl/sord937) sord937
2026-01-23 16:53:34 +0100AndreiDuma(~AndreiDum@user/AndreiDuma) AndreiDuma
2026-01-23 16:54:37 +0100AndreiDuma_(~AndreiDum@user/AndreiDuma) AndreiDuma
2026-01-23 16:55:36 +0100AndreiDuma_(~AndreiDum@user/AndreiDuma) ()
2026-01-23 16:56:28 +0100AndreiDuma(~AndreiDum@user/AndreiDuma) ()
2026-01-23 16:58:54 +0100weary-traveler(~user@user/user363627) (Remote host closed the connection)
2026-01-23 16:59:56 +0100 <mauke> bwe: you might not even need the "modify" part. atomicWriteIORef is also an option, then
2026-01-23 17:02:15 +0100 <mauke> for the "modify" version, you supply a function of type `a -> (a, b)` where the argument is the old value stored in the IORef, the first component of the result is the new value to be stored in the IORef, and the second component of the result is the value to return from the whole operation
2026-01-23 17:03:59 +0100 <mauke> so if you can compute the new value without access to the old value, you can ignore the argument: atomicModifyIORef' myref (\_ -> (newvalue, ()))
2026-01-23 17:04:33 +0100 <mauke> which is roughly equivalent to atomicWriteIORef myref newvalue (modulo strictness)
2026-01-23 17:05:07 +0100Digitteknohippie(~user@user/digit) Digit
2026-01-23 17:05:21 +0100Digit(~user@user/digit) (Ping timeout: 252 seconds)
2026-01-23 17:20:02 +0100st_aldini(~Thunderbi@136.48.46.187) (Quit: st_aldini)
2026-01-23 17:29:51 +0100 <chromoblob> Leary: i like your indentation, but code is hard to undersrand
2026-01-23 17:31:15 +0100Googulator(~Googulato@team.broadbit.hu) (Ping timeout: 272 seconds)
2026-01-23 17:32:43 +0100Zemy_(~Zemy@72.178.108.235) (Remote host closed the connection)
2026-01-23 17:32:57 +0100Zemy(~Zemy@72.178.108.235)
2026-01-23 17:33:45 +0100 <geekosaur> that's normal 🙂
2026-01-23 17:39:08 +0100qqq(~qqq@185.54.21.105) (Quit: Lost terminal)
2026-01-23 17:47:15 +0100ljdarj(~Thunderbi@user/ljdarj) (Quit: ljdarj)
2026-01-23 17:47:36 +0100ljdarj(~Thunderbi@user/ljdarj) ljdarj
2026-01-23 17:48:01 +0100merijn(~merijn@77.242.116.146) (Ping timeout: 264 seconds)
2026-01-23 17:50:11 +0100Psychotic1(~Psychotic@2600:1007:b0a4:acff:921e:44c6:4ad9:edda)