2025/10/14

2025-10-14 00:00:25 +0200__monty__(~toonn@user/toonn) (Quit: leaving)
2025-10-14 00:01:00 +0200ystael_(~ystael@user/ystael) (Ping timeout: 256 seconds)
2025-10-14 00:03:19 +0200Googulator30(~Googulato@2a01-036d-0106-03fa-dc7a-fb6e-71bb-aaf0.pool6.digikabel.hu)
2025-10-14 00:06:59 +0200Googulator10(~Googulato@2a01-036d-0106-03fa-dc7a-fb6e-71bb-aaf0.pool6.digikabel.hu) (Ping timeout: 250 seconds)
2025-10-14 00:07:30 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-10-14 00:09:25 +0200tromp(~textual@2001:1c00:3487:1b00:f86b:2618:bf3:3b08) (Quit: My iMac has gone to sleep. ZZZzzz…)
2025-10-14 00:11:30 +0200CiaoSen(~Jura@2a02:8071:64e1:da0:5a47:caff:fe78:33db) (Ping timeout: 256 seconds)
2025-10-14 00:12:37 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 260 seconds)
2025-10-14 00:15:38 +0200ec(~ec@gateway/tor-sasl/ec) (Remote host closed the connection)
2025-10-14 00:16:33 +0200ec(~ec@gateway/tor-sasl/ec) ec
2025-10-14 00:18:17 +0200jmcantrell(~weechat@user/jmcantrell) (Ping timeout: 256 seconds)
2025-10-14 00:20:29 +0200jmcantrell(~weechat@user/jmcantrell) jmcantrell
2025-10-14 00:23:15 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-10-14 00:30:11 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 256 seconds)
2025-10-14 00:33:46 +0200Square3(~Square@user/square) Square
2025-10-14 00:33:55 +0200pera(~pera@user/pera) (Quit: leaving)
2025-10-14 00:37:14 +0200Square(~Square4@user/square) (Ping timeout: 248 seconds)
2025-10-14 00:41:17 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-10-14 00:45:35 +0200peterbecich(~Thunderbi@syn-172-222-148-214.res.spectrum.com) peterbecich
2025-10-14 00:45:58 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 246 seconds)
2025-10-14 00:46:18 +0200tomku(~tomku@user/tomku) (Ping timeout: 248 seconds)
2025-10-14 00:46:51 +0200machinedgod(~machinedg@d75-159-126-101.abhsia.telus.net) machinedgod
2025-10-14 00:47:53 +0200ljdarj(~Thunderbi@user/ljdarj) (Ping timeout: 244 seconds)
2025-10-14 00:48:20 +0200tomku(~tomku@user/tomku) tomku
2025-10-14 00:51:02 +0200vanishingideal(~vanishing@user/vanishingideal) vanishingideal
2025-10-14 00:57:04 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-10-14 01:01:56 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 256 seconds)
2025-10-14 01:03:32 +0200ljdarj(~Thunderbi@user/ljdarj) ljdarj
2025-10-14 01:11:00 +0200Googulator30(~Googulato@2a01-036d-0106-03fa-dc7a-fb6e-71bb-aaf0.pool6.digikabel.hu) (Quit: Client closed)
2025-10-14 01:11:02 +0200Googulator27(~Googulato@2a01-036d-0106-03fa-dc7a-fb6e-71bb-aaf0.pool6.digikabel.hu)
2025-10-14 01:12:51 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-10-14 01:13:34 +0200emmanuelux(~emmanuelu@user/emmanuelux) emmanuelux
2025-10-14 01:17:57 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 260 seconds)
2025-10-14 01:22:22 +0200Googulator5(~Googulato@2a01-036d-0106-03fa-dc7a-fb6e-71bb-aaf0.pool6.digikabel.hu)
2025-10-14 01:25:43 +0200peterbecich(~Thunderbi@syn-172-222-148-214.res.spectrum.com) (Ping timeout: 256 seconds)
2025-10-14 01:25:51 +0200Googulator27(~Googulato@2a01-036d-0106-03fa-dc7a-fb6e-71bb-aaf0.pool6.digikabel.hu) (Ping timeout: 250 seconds)
2025-10-14 01:27:05 +0200machinedgod(~machinedg@d75-159-126-101.abhsia.telus.net) (Quit: Lost terminal)
2025-10-14 01:30:11 +0200jmcantrell(~weechat@user/jmcantrell) (Quit: WeeChat 4.7.1)
2025-10-14 01:31:07 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-10-14 01:35:55 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 256 seconds)
2025-10-14 01:40:37 +0200Googulator51(~Googulato@2a01-036d-0106-03fa-dc7a-fb6e-71bb-aaf0.pool6.digikabel.hu)
2025-10-14 01:40:43 +0200Googulator5(~Googulato@2a01-036d-0106-03fa-dc7a-fb6e-71bb-aaf0.pool6.digikabel.hu) (Quit: Client closed)
2025-10-14 01:41:14 +0200Adeon(sid418992@id-418992.lymington.irccloud.com) (Server closed connection)
2025-10-14 01:41:26 +0200Adeon(sid418992@id-418992.lymington.irccloud.com) Adeon
2025-10-14 01:42:12 +0200jmcantrell(~weechat@user/jmcantrell) jmcantrell
2025-10-14 01:46:30 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-10-14 01:48:42 +0200Tuplanolla(~Tuplanoll@91-159-187-167.elisa-laajakaista.fi) (Quit: Leaving.)
2025-10-14 01:49:21 +0200jmcantrell(~weechat@user/jmcantrell) (Quit: WeeChat 4.7.1)
2025-10-14 01:50:01 +0200 <dcpagan> Codensity is missing a MonadError instance.
2025-10-14 01:50:12 +0200 <dcpagan> I had to roll one up with this: "catchError m k = lift $ catchError (lowerCodensity m) (lowerCodensity . k)"
2025-10-14 01:51:36 +0200 <dcpagan> Also, "shift" is defined as "shift f = Codensity (lowerCodensity . f)". I should look more into delimited continuations and their applications in exception-handling.
2025-10-14 01:51:47 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 256 seconds)
2025-10-14 01:53:07 +0200machinedgod(~machinedg@d75-159-126-101.abhsia.telus.net) machinedgod
2025-10-14 02:02:18 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-10-14 02:07:55 +0200bgg(~bgg@2a01:e0a:819:1510:438b:91ce:16bb:429f)
2025-10-14 02:09:00 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 244 seconds)
2025-10-14 02:17:27 +0200L29Ah(~L29Ah@wikipedia/L29Ah) L29Ah
2025-10-14 02:18:13 +0200inline(~inlinE@ip-178-202-059-161.um47.pools.vodafone-ip.de) Inline
2025-10-14 02:20:20 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-10-14 02:25:13 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 256 seconds)
2025-10-14 02:26:02 +0200acidjnk(~acidjnk@p200300d6e7171943fcd8740620ad93e7.dip0.t-ipconnect.de) (Ping timeout: 248 seconds)
2025-10-14 02:29:59 +0200trickard_(~trickard@cpe-54-98-47-163.wireline.com.au) (Read error: Connection reset by peer)
2025-10-14 02:31:12 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-10-14 02:32:31 +0200trickard_(~trickard@cpe-54-98-47-163.wireline.com.au)
2025-10-14 02:33:05 +0200califax(~califax@user/califx) (Remote host closed the connection)
2025-10-14 02:35:18 +0200califax(~califax@user/califx) califx
2025-10-14 02:35:59 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 256 seconds)
2025-10-14 02:36:43 +0200ttybitnik(~ttybitnik@user/wolper) (Quit: Fading out...)
2025-10-14 02:45:40 +0200trickard_(~trickard@cpe-54-98-47-163.wireline.com.au) (Ping timeout: 246 seconds)
2025-10-14 02:46:04 +0200trickard_(~trickard@cpe-54-98-47-163.wireline.com.au)
2025-10-14 02:47:00 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-10-14 02:48:28 +0200otto_s(~user@p4ff2701e.dip0.t-ipconnect.de) (Ping timeout: 256 seconds)
2025-10-14 02:50:19 +0200otto_s(~user@p4ff27382.dip0.t-ipconnect.de)
2025-10-14 02:50:55 +0200xff0x(~xff0x@2405:6580:b080:900:f3f6:c4a2:4d90:7f3d) (Ping timeout: 246 seconds)
2025-10-14 02:51:53 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 244 seconds)
2025-10-14 02:59:28 +0200Square(~Square4@user/square) Square
2025-10-14 03:00:22 +0200vanishingideal(~vanishing@user/vanishingideal) (Ping timeout: 246 seconds)
2025-10-14 03:02:07 +0200Square3(~Square@user/square) (Ping timeout: 246 seconds)
2025-10-14 03:02:46 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-10-14 03:05:42 +0200Googulator67(~Googulato@2a01-036d-0106-03fa-dc7a-fb6e-71bb-aaf0.pool6.digikabel.hu)
2025-10-14 03:06:11 +0200Googulator51(~Googulato@2a01-036d-0106-03fa-dc7a-fb6e-71bb-aaf0.pool6.digikabel.hu) (Quit: Client closed)
2025-10-14 03:07:01 +0200vetkat(~vetkat@user/vetkat) (Ping timeout: 246 seconds)
2025-10-14 03:07:37 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 260 seconds)
2025-10-14 03:08:08 +0200vetkat(~vetkat@user/vetkat) vetkat
2025-10-14 03:11:42 +0200machinedgod(~machinedg@d75-159-126-101.abhsia.telus.net) (Ping timeout: 256 seconds)
2025-10-14 03:18:11 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-10-14 03:23:01 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 256 seconds)
2025-10-14 03:28:08 +0200Dhark8(~Shark8@c-174-56-102-109.hsd1.nm.comcast.net)
2025-10-14 03:29:30 +0200finsternis(~X@23.226.237.192) finsternis
2025-10-14 03:31:06 +0200Shark8(~Shark8@c-174-56-102-109.hsd1.nm.comcast.net) (Ping timeout: 248 seconds)
2025-10-14 03:33:59 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-10-14 03:35:41 +0200Googulator67(~Googulato@2a01-036d-0106-03fa-dc7a-fb6e-71bb-aaf0.pool6.digikabel.hu) (Quit: Client closed)
2025-10-14 03:35:42 +0200Googulator39(~Googulato@2a01-036d-0106-03fa-dc7a-fb6e-71bb-aaf0.pool6.digikabel.hu)
2025-10-14 03:38:53 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 256 seconds)
2025-10-14 03:39:56 +0200Axman6(~Axman6@user/axman6) Axman6
2025-10-14 03:49:45 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-10-14 03:51:17 +0200xff0x(~xff0x@fsb6a9491c.tkyc517.ap.nuro.jp)
2025-10-14 03:56:27 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 256 seconds)
2025-10-14 03:57:47 +0200peterbecich(~Thunderbi@syn-172-222-148-214.res.spectrum.com) peterbecich
2025-10-14 03:57:59 +0200jmcantrell(~weechat@user/jmcantrell) jmcantrell
2025-10-14 04:00:56 +0200trickard_trickard
2025-10-14 04:07:45 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-10-14 04:12:53 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 256 seconds)
2025-10-14 04:19:38 +0200haltsolver(~cmo@2604:3d09:207f:8000::d1dc)
2025-10-14 04:20:51 +0200Googulator39(~Googulato@2a01-036d-0106-03fa-dc7a-fb6e-71bb-aaf0.pool6.digikabel.hu) (Quit: Client closed)
2025-10-14 04:20:51 +0200Googulator47(~Googulato@2a01-036d-0106-03fa-dc7a-fb6e-71bb-aaf0.pool6.digikabel.hu)
2025-10-14 04:21:14 +0200Adeon(sid418992@id-418992.lymington.irccloud.com) (Server closed connection)
2025-10-14 04:21:26 +0200Adeon(sid418992@id-418992.lymington.irccloud.com) Adeon
2025-10-14 04:23:32 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-10-14 04:24:14 +0200haltsolver(~cmo@2604:3d09:207f:8000::d1dc) (Ping timeout: 256 seconds)
2025-10-14 04:28:46 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 256 seconds)
2025-10-14 04:32:07 +0200ljdarj(~Thunderbi@user/ljdarj) (Ping timeout: 244 seconds)
2025-10-14 04:36:07 +0200td_(~td@i53870910.versanet.de) (Ping timeout: 256 seconds)
2025-10-14 04:37:54 +0200td_(~td@i53870911.versanet.de) td_
2025-10-14 04:39:17 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-10-14 04:44:37 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 256 seconds)
2025-10-14 04:47:26 +0200califax_(~califax@user/califx) califx
2025-10-14 04:48:10 +0200califax(~califax@user/califx) (Ping timeout: 272 seconds)
2025-10-14 04:48:39 +0200califax_califax
2025-10-14 04:51:59 +0200Unicorn_Princess(~Unicorn_P@user/Unicorn-Princess/x-3540542) (Remote host closed the connection)
2025-10-14 04:54:28 +0200peterbecich(~Thunderbi@syn-172-222-148-214.res.spectrum.com) (Ping timeout: 246 seconds)
2025-10-14 04:55:06 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-10-14 04:56:31 +0200jmcantrell(~weechat@user/jmcantrell) (Ping timeout: 256 seconds)
2025-10-14 04:57:39 +0200humasect(~humasect@dyn-192-249-132-90.nexicom.net) humasect
2025-10-14 05:00:12 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 260 seconds)
2025-10-14 05:10:53 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-10-14 05:14:12 +0200Square(~Square4@user/square) (Ping timeout: 260 seconds)
2025-10-14 05:17:34 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 246 seconds)
2025-10-14 05:18:16 +0200annamalai(~annamalai@2409:4042:4e3c:ee1e::9e4a:2910) annamalai
2025-10-14 05:19:19 +0200inline(~inlinE@ip-178-202-059-161.um47.pools.vodafone-ip.de) (Ping timeout: 246 seconds)
2025-10-14 05:28:56 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-10-14 05:30:21 +0200jmcantrell(~weechat@user/jmcantrell) jmcantrell
2025-10-14 05:33:55 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 256 seconds)
2025-10-14 05:44:43 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-10-14 05:49:47 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 260 seconds)
2025-10-14 06:00:12 +0200aforemny(~aforemny@2001:9e8:6cd9:6800:96c8:2246:a5e7:93e3) aforemny
2025-10-14 06:00:14 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-10-14 06:01:41 +0200aforemny_(~aforemny@i59F4C4D3.versanet.de) (Ping timeout: 256 seconds)
2025-10-14 06:05:05 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 256 seconds)
2025-10-14 06:08:49 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-10-14 06:13:34 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 246 seconds)
2025-10-14 06:19:36 +0200 <jackdk> Some libraries use MonadFail as an error-reporting mechanism, but I think this is a historical error. These days I'd only use MonadFail to handle pattern-match failures in do expressions
2025-10-14 06:20:37 +0200Googulator1(~Googulato@2a01-036d-0106-03fa-dc7a-fb6e-71bb-aaf0.pool6.digikabel.hu)
2025-10-14 06:20:51 +0200Googulator47(~Googulato@2a01-036d-0106-03fa-dc7a-fb6e-71bb-aaf0.pool6.digikabel.hu) (Quit: Client closed)
2025-10-14 06:24:32 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-10-14 06:25:21 +0200craunts79533538(~craunts@136.158.7.194) (Quit: The Lounge - https://thelounge.chat)
2025-10-14 06:28:01 +0200craunts79533538(~craunts@136.158.7.194)
2025-10-14 06:29:27 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 256 seconds)
2025-10-14 06:30:31 +0200peterbecich(~Thunderbi@syn-172-222-148-214.res.spectrum.com) peterbecich
2025-10-14 06:33:34 +0200werneta(~werneta@syn-071-083-160-242.res.spectrum.com) werneta
2025-10-14 06:40:20 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-10-14 06:42:20 +0200rvalue-(~rvalue@about/hackers/rvalue) rvalue
2025-10-14 06:42:21 +0200rvalue-(~rvalue@about/hackers/rvalue) (Excess Flood)
2025-10-14 06:42:53 +0200rvalue-(~rvalue@about/hackers/rvalue) rvalue
2025-10-14 06:42:54 +0200rvalue-(~rvalue@about/hackers/rvalue) (Excess Flood)
2025-10-14 06:43:13 +0200rvalue(~rvalue@about/hackers/rvalue) (Ping timeout: 264 seconds)
2025-10-14 06:45:20 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 256 seconds)
2025-10-14 06:46:11 +0200rvalue(~rvalue@about/hackers/rvalue) rvalue
2025-10-14 06:46:12 +0200rvalue(~rvalue@about/hackers/rvalue) (Excess Flood)
2025-10-14 06:49:31 +0200rvalue(~rvalue@about/hackers/rvalue) rvalue
2025-10-14 06:49:36 +0200rvalue(~rvalue@about/hackers/rvalue) (Excess Flood)
2025-10-14 06:50:02 +0200rvalue(~rvalue@about/hackers/rvalue) rvalue
2025-10-14 06:50:03 +0200rvalue(~rvalue@about/hackers/rvalue) (Excess Flood)
2025-10-14 06:50:37 +0200Googulator1(~Googulato@2a01-036d-0106-03fa-dc7a-fb6e-71bb-aaf0.pool6.digikabel.hu) (Quit: Client closed)
2025-10-14 06:50:40 +0200Googulator97(~Googulato@2a01-036d-0106-03fa-dc7a-fb6e-71bb-aaf0.pool6.digikabel.hu)
2025-10-14 06:56:07 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-10-14 06:56:22 +0200annamalai(~annamalai@2409:4042:4e3c:ee1e::9e4a:2910) (Remote host closed the connection)
2025-10-14 06:57:02 +0200annamalai(~annamalai@157.32.210.114) annamalai
2025-10-14 06:57:30 +0200michalz(~michalz@185.246.207.221)
2025-10-14 07:02:34 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 246 seconds)
2025-10-14 07:02:54 +0200Adeon(sid418992@id-418992.lymington.irccloud.com) (Server closed connection)
2025-10-14 07:03:06 +0200Adeon(sid418992@id-418992.lymington.irccloud.com) Adeon
2025-10-14 07:06:08 +0200craunts79533538(~craunts@136.158.7.194) (Quit: The Lounge - https://thelounge.chat)
2025-10-14 07:09:44 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-10-14 07:13:56 +0200emmanuelux(~emmanuelu@user/emmanuelux) (Read error: Connection reset by peer)
2025-10-14 07:14:34 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 248 seconds)
2025-10-14 07:16:54 +0200synchromesh(~john@2406:5a00:2412:2c00:3507:235a:4a6c:ccc6) (Read error: Connection reset by peer)
2025-10-14 07:17:07 +0200takuan(~takuan@d8D86B9E9.access.telenet.be)
2025-10-14 07:18:03 +0200synchromesh(~john@2406:5a00:2412:2c00:6c29:d20b:9891:7dea) synchromesh
2025-10-14 07:25:17 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-10-14 07:25:24 +0200Googulator97(~Googulato@2a01-036d-0106-03fa-dc7a-fb6e-71bb-aaf0.pool6.digikabel.hu) (Quit: Client closed)
2025-10-14 07:25:36 +0200Googulator97(~Googulato@2a01-036d-0106-03fa-dc7a-fb6e-71bb-aaf0.pool6.digikabel.hu)
2025-10-14 07:30:05 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 256 seconds)
2025-10-14 07:31:56 +0200poscat(~poscat@user/poscat) (Remote host closed the connection)
2025-10-14 07:34:46 +0200poscat(~poscat@user/poscat) poscat
2025-10-14 07:37:21 +0200jmcantrell(~weechat@user/jmcantrell) (Quit: WeeChat 4.7.1)
2025-10-14 07:41:04 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-10-14 07:45:58 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 246 seconds)
2025-10-14 07:50:13 +0200 <dminuoso> jackdk: Regarding botan bindings, I think any approach focusing on native bindings to a cryptographic library is more healthy both on on a security perspective as well as future proofing.
2025-10-14 07:50:20 +0200Sgeo(~Sgeo@user/sgeo) (Read error: Connection reset by peer)
2025-10-14 07:51:02 +0200 <dminuoso> Especially since the crypton(ite) situation demonstrates, that even *if* we have some reliable cryptographic implementation it is dependent on probably just a single person. Having an ecosystem dependent on a bus-factor of 1 is just not healthy for the rest of hackage.
2025-10-14 07:52:05 +0200 <dminuoso> Not entirely sure if your comment was hinting at paying the botan person to work on crypton instead for a while.
2025-10-14 07:54:24 +0200 <jackdk> dminuoso: I agree with what you have written. I think binding a trusted native implementation is safer in the long run, and I am hopeful we can move the ecosystem onto something like botan one day
2025-10-14 07:55:12 +0200 <jackdk> And to be clear, I do not think paying the botan person to shift to crypton would be a good idea
2025-10-14 07:57:06 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-10-14 08:00:28 +0200peterbecich(~Thunderbi@syn-172-222-148-214.res.spectrum.com) (Ping timeout: 260 seconds)
2025-10-14 08:02:23 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 256 seconds)
2025-10-14 08:10:20 +0200itaipu(~itaipu@168.121.97.28) (Ping timeout: 256 seconds)
2025-10-14 08:10:44 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-10-14 08:14:55 +0200jmcantrell(~weechat@user/jmcantrell) jmcantrell
2025-10-14 08:15:37 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 264 seconds)
2025-10-14 08:26:31 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-10-14 08:31:22 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 248 seconds)
2025-10-14 08:42:19 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-10-14 08:49:26 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 256 seconds)
2025-10-14 08:53:43 +0200jmcantrell(~weechat@user/jmcantrell) (Quit: WeeChat 4.7.1)
2025-10-14 09:00:01 +0200caconym7478798(~caconym@user/caconym) (Quit: bye)
2025-10-14 09:00:21 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-10-14 09:00:41 +0200caconym7478798(~caconym@user/caconym) caconym
2025-10-14 09:04:37 +0200werneta(~werneta@syn-071-083-160-242.res.spectrum.com) (Ping timeout: 260 seconds)
2025-10-14 09:05:12 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 260 seconds)
2025-10-14 09:11:44 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-10-14 09:14:36 +0200itaipu(~itaipu@168.121.97.28) itaipu
2025-10-14 09:16:37 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 246 seconds)
2025-10-14 09:17:59 +0200craunts79533538(~craunts@136.158.7.194)
2025-10-14 09:19:43 +0200CiaoSen(~Jura@2a02:8071:64e1:da0:5a47:caff:fe78:33db) CiaoSen
2025-10-14 09:26:17 +0200vanishingideal(~vanishing@user/vanishingideal) vanishingideal
2025-10-14 09:27:57 +0200ByronJohnson(~bairyn@MAIL.DIGITALKINGDOM.ORG) (Ping timeout: 260 seconds)
2025-10-14 09:29:17 +0200ByronJohnson(~bairyn@MAIL.DIGITALKINGDOM.ORG) ByronJohnson
2025-10-14 09:38:44 +0200Adeon(sid418992@id-418992.lymington.irccloud.com) (Server closed connection)
2025-10-14 09:38:56 +0200Adeon(sid418992@id-418992.lymington.irccloud.com) Adeon
2025-10-14 09:40:26 +0200ft(~ft@p4fc2a207.dip0.t-ipconnect.de) (Quit: leaving)
2025-10-14 09:52:27 +0200gustrb(~gustrb@191.243.134.87) (Ping timeout: 260 seconds)
2025-10-14 09:55:20 +0200wz1000(~zubin@static.11.113.47.78.clients.your-server.de) (Ping timeout: 245 seconds)
2025-10-14 09:56:28 +0200sshine(~simon@dao.mechanicus.xyz) (Ping timeout: 265 seconds)
2025-10-14 09:56:34 +0200tomsmeding(~tomsmedin@user/tomsmeding) (Ping timeout: 256 seconds)
2025-10-14 09:58:54 +0200Googulator97Googulator
2025-10-14 09:59:20 +0200merijn(~merijn@77.242.116.146) merijn
2025-10-14 09:59:39 +0200humasect(~humasect@dyn-192-249-132-90.nexicom.net) (Quit: Leaving...)
2025-10-14 10:02:44 +0200tomsmeding(~tomsmedin@user/tomsmeding) tomsmeding
2025-10-14 10:03:05 +0200sshine(~simon@dao.mechanicus.xyz) sshine
2025-10-14 10:05:36 +0200gustrb(~gustrb@191.243.134.87)
2025-10-14 10:08:30 +0200wz1000(~zubin@static.11.113.47.78.clients.your-server.de)
2025-10-14 10:10:34 +0200gustrb(~gustrb@191.243.134.87) (Ping timeout: 248 seconds)
2025-10-14 10:14:37 +0200Googulator(~Googulato@2a01-036d-0106-03fa-dc7a-fb6e-71bb-aaf0.pool6.digikabel.hu) (Quit: Client closed)
2025-10-14 10:14:51 +0200Googulator(~Googulato@2a01-036d-0106-03fa-dc7a-fb6e-71bb-aaf0.pool6.digikabel.hu)
2025-10-14 10:21:32 +0200adig(~adi@86.123.72.40) adig
2025-10-14 10:21:38 +0200comerijn(~merijn@77.242.116.146) merijn
2025-10-14 10:21:42 +0200adig(~adi@86.123.72.40) ()
2025-10-14 10:22:40 +0200fp(~Thunderbi@2001:708:20:1406::10c5) fp
2025-10-14 10:24:38 +0200merijn(~merijn@77.242.116.146) (Ping timeout: 256 seconds)
2025-10-14 10:27:51 +0200gustrb(~gustrb@191.243.134.87)
2025-10-14 10:33:01 +0200gustrb(~gustrb@191.243.134.87) (Ping timeout: 264 seconds)
2025-10-14 10:33:49 +0200sord937(~sord937@gateway/tor-sasl/sord937) sord937
2025-10-14 10:35:38 +0200Googulator(~Googulato@2a01-036d-0106-03fa-dc7a-fb6e-71bb-aaf0.pool6.digikabel.hu) (Quit: Client closed)
2025-10-14 10:35:42 +0200Googulator66(~Googulato@2a01-036d-0106-03fa-dc7a-fb6e-71bb-aaf0.pool6.digikabel.hu)
2025-10-14 10:37:47 +0200gustrb(~gustrb@191.243.134.87)
2025-10-14 10:39:01 +0200comerijn(~merijn@77.242.116.146) (Ping timeout: 264 seconds)
2025-10-14 10:40:42 +0200chele(~chele@user/chele) chele
2025-10-14 10:42:52 +0200Googulator66Googulator
2025-10-14 10:44:30 +0200merijn(~merijn@77.242.116.146) merijn
2025-10-14 10:44:37 +0200acidjnk(~acidjnk@p200300d6e71719931c47ad226c4c8e20.dip0.t-ipconnect.de) acidjnk
2025-10-14 10:45:01 +0200gustrb(~gustrb@191.243.134.87) (Ping timeout: 256 seconds)
2025-10-14 10:48:32 +0200tzh(~tzh@c-76-115-131-146.hsd1.or.comcast.net) (Quit: zzz)
2025-10-14 10:49:22 +0200gustrb(~gustrb@191.243.134.87)
2025-10-14 10:50:45 +0200merijn(~merijn@77.242.116.146) (Ping timeout: 245 seconds)
2025-10-14 10:57:14 +0200adig(~adi@86.123.72.40) adig
2025-10-14 10:57:22 +0200adig(~adi@86.123.72.40) ()
2025-10-14 11:02:51 +0200kuribas(~user@2a02-1810-2825-6000-b5ac-98ee-b19a-ab1f.ip6.access.telenet.be) kuribas
2025-10-14 11:04:18 +0200merijn(~merijn@77.242.116.146) merijn
2025-10-14 11:05:43 +0200Googulator(~Googulato@2a01-036d-0106-03fa-dc7a-fb6e-71bb-aaf0.pool6.digikabel.hu) (Quit: Client closed)
2025-10-14 11:05:47 +0200Googulator56(~Googulato@2a01-036d-0106-03fa-dc7a-fb6e-71bb-aaf0.pool6.digikabel.hu)
2025-10-14 11:05:55 +0200Googulator56Googulator
2025-10-14 11:07:58 +0200bgamari(~bgamari@64.223.225.237) (Ping timeout: 256 seconds)
2025-10-14 11:11:25 +0200merijn(~merijn@77.242.116.146) (Ping timeout: 264 seconds)
2025-10-14 11:18:39 +0200OWS(~Shark8@c-174-56-102-109.hsd1.nm.comcast.net)
2025-10-14 11:19:51 +0200merijn(~merijn@77.242.116.146) merijn
2025-10-14 11:20:25 +0200bgamari(~bgamari@64.223.200.137)
2025-10-14 11:21:51 +0200Dhark8(~Shark8@c-174-56-102-109.hsd1.nm.comcast.net) (Ping timeout: 256 seconds)
2025-10-14 11:24:58 +0200mreh(~matthew@host86-146-25-125.range86-146.btcentralplus.com) mreh
2025-10-14 11:27:14 +0200 <mreh> Is there a Semigroup instance for Map that is based on `unionWith (<>)` before I implement my own? I can't find one already.
2025-10-14 11:28:05 +0200bgamari(~bgamari@64.223.200.137) (Ping timeout: 256 seconds)
2025-10-14 11:28:20 +0200 <mreh> instance (Semigroup a, Ord k) => Semigroup (MergeMap k a) where MergeMap m <> MergeMap n = MergeMap $ unionWith (<>) m n
2025-10-14 11:28:29 +0200 <mreh> seems to fit the bill for what I'm doing
2025-10-14 11:28:43 +0200 <merijn> mreh: There is one, but it's inconvenient to use
2025-10-14 11:28:56 +0200 <mreh> merijn: oh?
2025-10-14 11:29:19 +0200 <merijn> I once tried to start a crusade to get the (imo more sensible) monoidal Map in containers, but no success
2025-10-14 11:30:01 +0200 <mreh> merijn: intuitively, it feels like the right default
2025-10-14 11:30:05 +0200 <merijn> mreh: There's like 3 or 4 libraries on Hackage that have monoidal map
2025-10-14 11:30:08 +0200 <tomsmeding> there are various packages on hackage that implement a monoidal map
2025-10-14 11:30:10 +0200 <tomsmeding> ^
2025-10-14 11:30:22 +0200 <merijn> In practice I tend to just do `unionWith (<>)` since it's more convenient
2025-10-14 11:30:51 +0200 <merijn> But every single time I want to `foldMap` a `Map` I am once again confronted with the default monoid of Map being shite >.<
2025-10-14 11:33:20 +0200Googulator(~Googulato@2a01-036d-0106-03fa-dc7a-fb6e-71bb-aaf0.pool6.digikabel.hu) (Quit: Client closed)
2025-10-14 11:34:11 +0200Googulator(~Googulato@2a01-036d-0106-03fa-dc7a-fb6e-71bb-aaf0.pool6.digikabel.hu)
2025-10-14 11:35:02 +0200bgamari(~bgamari@64.223.200.74)
2025-10-14 11:37:40 +0200 <mreh> oh yeah, it's too early, my eyes glazed over when reading Data.MonoidMap
2025-10-14 11:38:12 +0200 <mreh> v interesting how get is total when a is a Moniod
2025-10-14 11:46:48 +0200califax(~califax@user/califx) (Ping timeout: 272 seconds)
2025-10-14 11:51:00 +0200notzmv(~umar@user/notzmv) (Read error: Connection reset by peer)
2025-10-14 11:52:53 +0200 <dminuoso> merijn: Honestly I think much of Haskell typeclasses would be far more usable if we had an ergonomic way of just picking/swapping out instances other than newtype wrappers.
2025-10-14 11:53:24 +0200 <dminuoso> And yes, we'd give up guarantees on coherence that apply to some very obscure usecases...
2025-10-14 11:54:15 +0200mochie(~mochie@user/mochie) mochie
2025-10-14 11:54:20 +0200 <merijn> dminuoso: Hard disagree
2025-10-14 11:54:44 +0200 <merijn> I've been doing Scala for the past 2 years and the fact that implicit's let you do that is a giant nightmare
2025-10-14 11:56:00 +0200 <dminuoso> Having all these newtypes with clear bias about what the author thought should be "the authoritative behavior for typeclass XYZ" is just annoying.
2025-10-14 11:56:09 +0200dhil(~dhil@5.151.29.137) dhil
2025-10-14 11:56:26 +0200 <dminuoso> Some libraries are more honest like `time` where you just dont get Eq on some newtypes because there's two equally good possibilities.
2025-10-14 11:58:06 +0200califax(~califax@user/califx) califx
2025-10-14 11:58:24 +0200 <dminuoso> merijn: I think it may be a tooling problem in scala if its unclear what implicit is in scope right now.
2025-10-14 12:00:29 +0200 <merijn> My main tooling problem is sbt. I'd kill for cabal's speed xD
2025-10-14 12:06:04 +0200 <haskellbridge> <Morj> At least with newtypes unlike in rust you don't have problems that "fn(&MyType) -> &MyNewtype" is impossible to write
2025-10-14 12:06:57 +0200mochie(~mochie@user/mochie) ()
2025-10-14 12:08:27 +0200 <haskellbridge> <Morj> I find that where I use newtypes for their instances, it's usually not a bad ergonomic to write. Like "getProduct . foldMap Product"
2025-10-14 12:09:16 +0200 <haskellbridge> <Morj> Would be cool if there was a combinator like "foldMap coerce" so that I only had to write the newtype name once
2025-10-14 12:09:18 +0200 <mreh> shouldn't you use coerce and type applications in that case?
2025-10-14 12:09:18 +0200__monty__(~toonn@user/toonn) toonn
2025-10-14 12:09:50 +0200 <haskellbridge> <Morj> I like being explicit
2025-10-14 12:09:55 +0200CiaoSen(~Jura@2a02:8071:64e1:da0:5a47:caff:fe78:33db) (Ping timeout: 245 seconds)
2025-10-14 12:09:58 +0200 <haskellbridge> <Morj> Also is coerce in microhs? ;-)
2025-10-14 12:10:26 +0200 <mreh> ¯\_(ツ)_/¯
2025-10-14 12:10:52 +0200 <mreh> are type applications?
2025-10-14 12:11:01 +0200 <haskellbridge> <Morj> They at least are there
2025-10-14 12:12:21 +0200divlamir(~divlamir@user/divlamir) (Read error: Connection reset by peer)
2025-10-14 12:12:45 +0200divlamir(~divlamir@user/divlamir) divlamir
2025-10-14 12:14:34 +0200Adeon(sid418992@id-418992.lymington.irccloud.com) (Server closed connection)
2025-10-14 12:14:46 +0200Adeon(sid418992@id-418992.lymington.irccloud.com) Adeon
2025-10-14 12:15:07 +0200xff0x(~xff0x@fsb6a9491c.tkyc517.ap.nuro.jp) (Ping timeout: 256 seconds)
2025-10-14 12:15:34 +0200 <merijn> coerce is good, but type applications is bad imo
2025-10-14 12:16:02 +0200 <merijn> Ugly syntax and (worse) far too brittle in my opinion
2025-10-14 12:20:08 +0200 <merijn> You're relying on the order of type variables as part of the public interface of a library (which basically no library author considers for PVP decisions) and unless the library author explicitly `forall`'s the type variables on every function that's dependent on the whims of GHC
2025-10-14 12:20:20 +0200 <tomsmeding> type applications would be more robust if they're allowed only on functions with an explicit type variable ordering
2025-10-14 12:20:29 +0200 <tomsmeding> but then nobody would have used it because of the chicken-egg problem
2025-10-14 12:20:44 +0200 <merijn> Which is far from hypothetical, since we've already had at least one GHC release where a type system rejiggle changed the order of inferred variables, leading to breakage
2025-10-14 12:25:52 +0200merijn(~merijn@77.242.116.146) (Ping timeout: 260 seconds)
2025-10-14 12:33:31 +0200halloy7365(~halloy736@2404:4400:5446:4e00:c9d:2341:235f:e891)
2025-10-14 12:38:24 +0200merijn(~merijn@77.242.116.146) merijn
2025-10-14 12:44:10 +0200merijn(~merijn@77.242.116.146) (Ping timeout: 246 seconds)
2025-10-14 12:47:44 +0200yegor(~yegor@user/yegor) (Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in)
2025-10-14 12:48:01 +0200yegor(yegor@user/yegor) yegor
2025-10-14 12:50:11 +0200merijn(~merijn@77.242.116.146) merijn
2025-10-14 12:52:48 +0200halloy7365(~halloy736@2404:4400:5446:4e00:c9d:2341:235f:e891) (Quit: halloy7365)
2025-10-14 12:53:13 +0200CiaoSen(~Jura@2a02:8071:64e1:da0:5a47:caff:fe78:33db) CiaoSen
2025-10-14 12:54:55 +0200chele(~chele@user/chele) (Ping timeout: 245 seconds)
2025-10-14 13:00:05 +0200caconym7478798(~caconym@user/caconym) (Quit: bye)
2025-10-14 13:01:29 +0200caconym7478798(~caconym@user/caconym) caconym
2025-10-14 13:08:24 +0200Zemy(~Zemy@syn-076-184-041-021.res.spectrum.com) (Read error: Connection reset by peer)
2025-10-14 13:08:29 +0200Zemy_(~Zemy@2600:100c:b035:5997:18fe:25ff:fe03:e2c)
2025-10-14 13:09:00 +0200Zemy(~Zemy@syn-076-184-041-021.res.spectrum.com)
2025-10-14 13:10:25 +0200MelodyOwO(~MelodyOwO@user/MelodyOwO) MelodyOwO
2025-10-14 13:12:57 +0200Zemy_(~Zemy@2600:100c:b035:5997:18fe:25ff:fe03:e2c) (Ping timeout: 252 seconds)
2025-10-14 13:13:14 +0200 <dminuoso> Morj: Every time I stare at rust Im a bit confused how people willingly drift towards it.
2025-10-14 13:16:21 +0200 <dminuoso> Every time I dabbled with it, it felt more like most rust idioms exist to please the borrow checker, not because it leads to good semantics that you can reason about.
2025-10-14 13:16:37 +0200 <dminuoso> Even something mundane as writing a graph library is hell.
2025-10-14 13:17:01 +0200 <lortabac> Morj: there is 'ala', which is in lens (and other packages too)
2025-10-14 13:17:06 +0200 <lortabac> > ala Sum foldMap [1,2,3]
2025-10-14 13:17:07 +0200 <lambdabot> 6
2025-10-14 13:17:30 +0200 <dminuoso> But maybe I haven't spent enough time with Rust yet, and you need a state of enlightenment before you can see it shine.
2025-10-14 13:18:28 +0200peutri_(~peutri@bobo.desast.re) (Ping timeout: 246 seconds)
2025-10-14 13:19:04 +0200 <merijn> dminuoso: It sounds like you just don't have the problems Rust solves
2025-10-14 13:19:29 +0200 <merijn> dminuoso: Rust seems great IFF I couldn't afford a garbage collector/less explicit memory control
2025-10-14 13:19:33 +0200 <merijn> dminuoso: If you
2025-10-14 13:19:48 +0200 <merijn> If you're fine with GC and less memory control, you're better off just writing Haskell
2025-10-14 13:20:01 +0200 <merijn> And 90-95% of code just does not require anything like that
2025-10-14 13:20:14 +0200 <dminuoso> merijn: Maybe I'm just biased a bit *because* I have learned to work with C++ - in comparison Rust feels a lot more effort to avoid reference counting.
2025-10-14 13:20:15 +0200 <merijn> So I've never had a real use case to use Rust
2025-10-14 13:20:33 +0200 <merijn> dminuoso: I mean, you *can* just do reference counting in Rust afaik
2025-10-14 13:20:49 +0200 <dminuoso> Sure, but then you wouldn't need to borrow references.
2025-10-14 13:23:25 +0200xff0x(~xff0x@2405:6580:b080:900:c19d:50a:4f2f:38d7)
2025-10-14 13:27:12 +0200pavonia(~user@user/siracusa) (Read error: Connection reset by peer)
2025-10-14 13:28:00 +0200peutri(~peutri@bobo.desast.re) peutri
2025-10-14 13:31:33 +0200chele(~chele@user/chele) chele
2025-10-14 13:35:52 +0200Lord_of_Life(~Lord@user/lord-of-life/x-2819915) (Ping timeout: 260 seconds)
2025-10-14 13:36:25 +0200Lord_of_Life(~Lord@user/lord-of-life/x-2819915) Lord_of_Life
2025-10-14 13:43:03 +0200 <jackdk> merijn: Now that we have the machinery to deprecate instances, we could restart the crusade to fix the most cursed monoid instance
2025-10-14 13:43:40 +0200 <jackdk> merijn: Also, we now have RequiredTypeArguments which makes it clearer when one is expected to pass an explicit type (as opposed to using haddocks or Proxy arguments)
2025-10-14 13:44:01 +0200chromoblob(~chromoblo@user/chromob1ot1c) (Ping timeout: 246 seconds)
2025-10-14 13:44:50 +0200chromoblob(~chromoblo@user/chromob1ot1c) chromoblob\0
2025-10-14 13:46:07 +0200 <haskellbridge> <Morj> lortabac oh thanks, I remember there was something, but couldn't recall. This is the one I thought about
2025-10-14 13:46:41 +0200 <lortabac> jackdk: what is "the most cursed monoid instance"?
2025-10-14 13:47:02 +0200trickard(~trickard@cpe-54-98-47-163.wireline.com.au) (Read error: Connection reset by peer)
2025-10-14 13:47:16 +0200trickard_(~trickard@cpe-54-98-47-163.wireline.com.au)
2025-10-14 13:47:31 +0200 <jackdk> lortabac: I consider `instance Ord k => Monoid (Map k)` to be a massive footgun, and think `instance (Ord k, Semigroup v) => Monoid (Map k v)` to be a better canonical instance.
2025-10-14 13:47:33 +0200 <haskellbridge> <Morj> dminuoso It makes more sense to use rust if you're coming from c++. I don't think it's a good choice instead of haskell in most cases. I write rust at work nowadays: the high-perf libraries are great, the application around it could be improved a lot with a smart runtime and a gc
2025-10-14 13:48:28 +0200 <lortabac> jackdk: thanks, I didn't even know that instance existed
2025-10-14 13:48:47 +0200weary-traveler(~user@user/user363627) user363627
2025-10-14 13:48:56 +0200Square(~Square4@user/square) Square
2025-10-14 13:49:15 +0200chromoblob(~chromoblo@user/chromob1ot1c) (Ping timeout: 252 seconds)
2025-10-14 13:49:28 +0200 <jackdk> lortabac: I consider it a footgun because it often does almost what you want: merge two maps together. But when keys clash it keeps the value in the left map, which is often surprising
2025-10-14 13:50:25 +0200 <lortabac> indeed your proposal makes more sense
2025-10-14 13:52:37 +0200 <__monty__> It's a useful behavior IMO, some languages have an operator for that kind of merging.
2025-10-14 13:53:33 +0200chromoblob(~chromoblo@user/chromob1ot1c) chromoblob\0
2025-10-14 13:54:39 +0200 <jackdk> __monty__: People who want it will still be able to get it via `Map k (First v)` (`First` from `Data.Semigroup`)
2025-10-14 13:55:39 +0200 <lortabac> it's useful but it doesn't make sense as a canonical instance
2025-10-14 13:56:21 +0200 <lortabac> you can still make an operator with that behavior
2025-10-14 13:59:35 +0200Zemy_(~Zemy@2600:100c:b035:5997:3087:68ff:feb8:f43e)
2025-10-14 13:59:35 +0200Zemy(~Zemy@syn-076-184-041-021.res.spectrum.com) (Read error: Connection reset by peer)
2025-10-14 14:00:02 +0200Zemy(~Zemy@syn-076-184-041-021.res.spectrum.com)
2025-10-14 14:00:51 +0200Zemy_(~Zemy@2600:100c:b035:5997:3087:68ff:feb8:f43e) (Read error: Connection reset by peer)
2025-10-14 14:08:24 +0200Googulator(~Googulato@2a01-036d-0106-03fa-dc7a-fb6e-71bb-aaf0.pool6.digikabel.hu) (Quit: Client closed)
2025-10-14 14:08:41 +0200Googulator(~Googulato@2a01-036d-0106-03fa-dc7a-fb6e-71bb-aaf0.pool6.digikabel.hu)
2025-10-14 14:10:04 +0200inline(~inlinE@ip-178-202-059-161.um47.pools.vodafone-ip.de) Inline
2025-10-14 14:11:02 +0200Zemy_(~Zemy@2600:100c:b035:5997:4c73:91ff:fe3e:e2e1)
2025-10-14 14:11:02 +0200Zemy(~Zemy@syn-076-184-041-021.res.spectrum.com) (Read error: Connection reset by peer)
2025-10-14 14:12:12 +0200Zemy(~Zemy@syn-076-184-041-021.res.spectrum.com)
2025-10-14 14:15:16 +0200Zemy_(~Zemy@2600:100c:b035:5997:4c73:91ff:fe3e:e2e1) (Ping timeout: 256 seconds)
2025-10-14 14:16:29 +0200 <mreh> jackdk: what happened to Queensland FP?
2025-10-14 14:17:42 +0200 <mreh> lack of funding?
2025-10-14 14:19:26 +0200 <jackdk> mreh: Correct. Its funding was not renewed. The Brisbane Functional Programming Group, however, resurrected itself after the pandemic: https://bfpg.org
2025-10-14 14:20:17 +0200 <mreh> jackdk: cool, I enjoyed that talk you gave on reflex a while back
2025-10-14 14:22:19 +0200 <jackdk> mreh: Thanks, that's good of you to say
2025-10-14 14:24:04 +0200 <mreh> recognised the name
2025-10-14 14:25:09 +0200inline(~inlinE@ip-178-202-059-161.um47.pools.vodafone-ip.de) (Quit: Leaving)
2025-10-14 14:25:16 +0200mrehwishes there was a Haskell meetup in London again
2025-10-14 14:25:23 +0200 <merijn> jackdk: You've got my signature :p
2025-10-14 14:25:27 +0200rvalue(~rvalue@about/hackers/rvalue) rvalue
2025-10-14 14:25:29 +0200rvalue(~rvalue@about/hackers/rvalue) (Excess Flood)
2025-10-14 14:25:37 +0200Googulator(~Googulato@2a01-036d-0106-03fa-dc7a-fb6e-71bb-aaf0.pool6.digikabel.hu) (Quit: Client closed)
2025-10-14 14:25:39 +0200Googulator81(~Googulato@2a01-036d-0106-03fa-dc7a-fb6e-71bb-aaf0.pool6.digikabel.hu)
2025-10-14 14:25:55 +0200 <merijn> __monty__: It's useful, but not AS useful as the semigroup version
2025-10-14 14:26:07 +0200 <merijn> __monty__: I've used the semigroup monoid on Map hundreds of times
2025-10-14 14:26:13 +0200 <merijn> The left-biased merge never
2025-10-14 14:26:22 +0200 <merijn> And when you want that you can just use `unions`
2025-10-14 14:27:01 +0200 <jackdk> mreh: I would've thought there'd be a fair number of Haskellers in London?
2025-10-14 14:27:23 +0200 <mreh> there's no "just use" when you're using a Map in Writer :'(
2025-10-14 14:27:53 +0200 <merijn> mreh: Yes there is
2025-10-14 14:28:03 +0200 <merijn> mreh: It's called "Map k (First v)"
2025-10-14 14:28:36 +0200 <merijn> So the current behaviour is trivially reconstructible via a newtype wrapper on values
2025-10-14 14:28:49 +0200rvalue(~rvalue@about/hackers/rvalue) rvalue
2025-10-14 14:28:50 +0200rvalue(~rvalue@about/hackers/rvalue) (Excess Flood)
2025-10-14 14:29:30 +0200 <mreh> that's true
2025-10-14 14:31:34 +0200 <mreh> jackdk: I went to a meetup maybe 10 years ago, it's since folded
2025-10-14 14:31:52 +0200trickard_(~trickard@cpe-54-98-47-163.wireline.com.au) (Ping timeout: 260 seconds)
2025-10-14 14:32:08 +0200 <merijn> mreh: Yet another reason, the Semigroup version is superior :p
2025-10-14 14:32:19 +0200trickard_(~trickard@cpe-54-98-47-163.wireline.com.au)
2025-10-14 14:34:01 +0200rvalue(~rvalue@about/hackers/rvalue) rvalue
2025-10-14 14:36:42 +0200ski. o O ( <https://en.wikipedia.org/wiki/Monoid_ring> )
2025-10-14 14:43:55 +0200rvalue(~rvalue@about/hackers/rvalue) (Quit: bmV2ZXJnb25uYWdpdmV5b3V1cG5ldmVyZ29ubmFsZXR5b3Vkb3du)
2025-10-14 14:44:43 +0200 <tomsmeding> ski: why does that not open with "a monoid ring is a formal polynomial ring in a monoid with coefficient from a ring"
2025-10-14 14:45:42 +0200 <tomsmeding> perhaps that would be too "monoid in the category of endofunctors" for wikipedia
2025-10-14 14:46:05 +0200Googulator75(~Googulato@2a01-036d-0106-03fa-dc7a-fb6e-71bb-aaf0.pool6.digikabel.hu)
2025-10-14 14:46:12 +0200rvalue(~rvalue@about/hackers/rvalue) rvalue
2025-10-14 14:46:14 +0200Googulator81(~Googulato@2a01-036d-0106-03fa-dc7a-fb6e-71bb-aaf0.pool6.digikabel.hu) (Quit: Client closed)
2025-10-14 14:50:46 +0200Googulator49(~Googulato@2a01-036d-0106-03fa-dc7a-fb6e-71bb-aaf0.pool6.digikabel.hu)
2025-10-14 14:50:50 +0200Googulator75(~Googulato@2a01-036d-0106-03fa-dc7a-fb6e-71bb-aaf0.pool6.digikabel.hu) (Client Quit)
2025-10-14 15:00:52 +0200Googulator49Googulator
2025-10-14 15:03:45 +0200inline(~inlinE@ip-178-202-059-161.um47.pools.vodafone-ip.de) Inline
2025-10-14 15:05:42 +0200kuribas(~user@2a02-1810-2825-6000-b5ac-98ee-b19a-ab1f.ip6.access.telenet.be) (Ping timeout: 256 seconds)
2025-10-14 15:07:37 +0200CiaoSen(~Jura@2a02:8071:64e1:da0:5a47:caff:fe78:33db) (Ping timeout: 244 seconds)
2025-10-14 15:14:49 +0200luna___(~luna@fedora/bittin) bittin
2025-10-14 15:15:49 +0200Googulator6(~Googulato@2a01-036d-0106-03fa-dc7a-fb6e-71bb-aaf0.pool6.digikabel.hu)
2025-10-14 15:16:13 +0200Googulator(~Googulato@2a01-036d-0106-03fa-dc7a-fb6e-71bb-aaf0.pool6.digikabel.hu) (Quit: Client closed)
2025-10-14 15:17:36 +0200inline(~inlinE@ip-178-202-059-161.um47.pools.vodafone-ip.de) (Ping timeout: 256 seconds)
2025-10-14 15:17:53 +0200inline(~inlinE@ip-178-202-059-142.um47.pools.vodafone-ip.de) Inline
2025-10-14 15:25:59 +0200bitdex(~bitdex@gateway/tor-sasl/bitdex) bitdex
2025-10-14 15:28:44 +0200 <ski> tomsmeding : i guess saying "polynomial" implies that the monoid is the free (commutative) monoid (hm, for "formal polynomial", would that be cofree monoid ?)
2025-10-14 15:30:07 +0200bitdex(~bitdex@gateway/tor-sasl/bitdex) (Remote host closed the connection)
2025-10-14 15:30:45 +0200bitdex(~bitdex@gateway/tor-sasl/bitdex) bitdex
2025-10-14 15:44:10 +0200 <tomsmeding> ski: well, the article does say that the polynomials are formal ("set of formal sums")
2025-10-14 15:44:33 +0200 <tomsmeding> so whether the elements of G do something with each other is not relevant for how many elements rae in R[G], it seems
2025-10-14 15:44:58 +0200 <tomsmeding> if the sums weren't formal, this would be a module, would it not?
2025-10-14 15:45:00 +0200ystael(~ystael@user/ystael) ystael
2025-10-14 15:45:50 +0200 <tomsmeding> (I guess it would be a "monoid module")
2025-10-14 15:50:20 +0200 <ski> "More formally, `R[G]' is the free `R'-module on the set `G', endowed with `R'-linear multiplication defined on the base elements by `g·h := gh', where the left-hand side is understood as the multiplication in `R[G]' and the right-hand side is understood in `G'."
2025-10-14 15:51:30 +0200 <ski> "so whether the elements of G do something with each other is not relevant for how many elements rae in R[G], it seems" -- it affects multiplication of them, yea
2025-10-14 15:51:33 +0200weary-traveler(~user@user/user363627) (Remote host closed the connection)
2025-10-14 15:53:47 +0200 <ski> instead of combining monomials like `x * y^2' and `x^3 * z' into `x^4 * y^2 * z', amounting to bag/multiset merging (multiplication in the free commutative monoid), you get a not-necessarily-injective multiplication in the monoid
2025-10-14 15:56:59 +0200 <ski> (and yea, i was reminded of this, by the talk about `Monoid (Map k v)'. if we ignore the multiplication (and subtraction/negation) in the monoid ring, then `k' corresponds to the set of indeterminates (generators) in the "polynomials", and `v' corresponds to the monoid of coefficients)
2025-10-14 15:58:08 +0200 <tomsmeding> ski: "not-necessarily-injective" -- ah! right
2025-10-14 15:59:36 +0200 <tomsmeding> thanks :)
2025-10-14 16:01:19 +0200 <ski> the "formal" here means that when we write a (finite) sum of products of monoid elements and associated coefficients, this is just a suggestive notation for having a function from the monoid elements to the coefficients, with "finite support" (meaning only finitely many monoid elements map to non-zero coefficients)
2025-10-14 16:02:33 +0200 <ski> (iirc, in some rings, (ordinary) polynomials can be distinct (having distinct coefficients), while still having the same value at each possible input (being extensionally equal, the corresponding functions to the polynomials being equal))
2025-10-14 16:02:37 +0200fp(~Thunderbi@2001:708:20:1406::10c5) (Ping timeout: 246 seconds)
2025-10-14 16:05:05 +0200 <tomsmeding> polynomials on Z/2Z have a bunch of such "redundancies"
2025-10-14 16:06:11 +0200 <tomsmeding> but yeah I see where my understanding went wrong: I wasn't properly thinking about the fact that this R[G] is supposed to be a _ring_, and what the multiplication operation ought to do
2025-10-14 16:06:35 +0200 <tomsmeding> then the structure of the monoid suddenly comes into play
2025-10-14 16:07:18 +0200inline(~inlinE@ip-178-202-059-142.um47.pools.vodafone-ip.de) (Ping timeout: 252 seconds)
2025-10-14 16:07:48 +0200inline(~inlinE@ip-178-202-059-161.um47.pools.vodafone-ip.de) Inline
2025-10-14 16:08:42 +0200MelodyOwO(~MelodyOwO@user/MelodyOwO) (Quit: Leaving.)
2025-10-14 16:09:35 +0200 <ski> (oh, and when i said "formal polynomial", above, i had "formal power series in mind" .. so wondering whether that would involve a cofree, rather than free, monoid. cf. how direct sum (categorical coproduct) and direct product (categorical product) for *commutative* groups (as well as monoids) coincide, for a *finite* family of groups (or monoids), but are distinct for an infinite family. difference is that
2025-10-14 16:09:41 +0200 <ski> the direct sum case involves a function, with *finite support*, from the family indices to elements of the corresponding groups (monoids), while for direct product, it's arbitrary such functions. for arbitrary (not necessarily commutative/abelian) groups (monoids), though, the categorical coproduct case (called "free product") becomes a larger object. `g_0 * h * g_1' is no longer equal to `(g_0 * g_1) * h',
2025-10-14 16:09:47 +0200 <ski> so you can no longer keep track of a single element per group (monoid))
2025-10-14 16:10:58 +0200 <ski> now .. is there a use case for wanting to multiply `Map k v's, given `Monoid k' ?
2025-10-14 16:12:21 +0200 <tomsmeding> feels a bit far-fetched to me, not least because the result "invents new keys" that were not there in the original