2024/11/14

2024-11-14 00:01:51 +0100falafel(~falafel@2600:1700:99f4:2050:41b3:d17e:817a:4e83) falafel
2024-11-14 00:02:55 +0100Everything(~Everythin@46.211.104.82) (Quit: leaving)
2024-11-14 00:28:22 +0100Xe_(~Xe@perl/impostor/xe) Xe
2024-11-14 00:29:11 +0100peterbecich(~Thunderbi@syn-047-229-123-186.res.spectrum.com) peterbecich
2024-11-14 00:29:57 +0100acidjnk_new3(~acidjnk@p200300d6e7283f7100fa0b96aa6639bf.dip0.t-ipconnect.de) (Ping timeout: 248 seconds)
2024-11-14 00:32:33 +0100acidjnk_new3(~acidjnk@p200300d6e7283f717cba866c0fa9f7cd.dip0.t-ipconnect.de)
2024-11-14 00:47:47 +0100 <jackdk> I want to provide a type family-shaped helper that identifies the type of a record field, something like `FieldType "foo" MyRecord` reducing to `Bar`. I can get at the type of a field by looking at the fundep on the `HasField` class (GHC gives me in `instance HasField "foo" MyRecord Bar`, but is there a good idiom for binding and returning that type variable using a type family?
2024-11-14 00:48:23 +0100alexherbo2(~alexherbo@2a02-8440-3117-f07c-987b-fc29-77ee-addd.rev.sfr.net) (Remote host closed the connection)
2024-11-14 00:49:22 +0100CoolMa7(~CoolMa7@ip5f5b8957.dynamic.kabel-deutschland.de) (Quit: My Mac has gone to sleep. ZZZzzz…)
2024-11-14 00:49:54 +0100athostFI(~Atte@176-93-56-50.bb.dnainternet.fi)
2024-11-14 00:50:52 +0100alp(~alp@2001:861:e3d6:8f80:8dec:7d0f:9187:87d0) (Remote host closed the connection)
2024-11-14 00:51:04 +0100 <Axman6> This feels like it might be easier with generics-sop, but it's been a long time since I looked at any of these things
2024-11-14 00:51:40 +0100alp(~alp@2001:861:e3d6:8f80:cd0a:c39d:37b7:c1a3)
2024-11-14 00:53:05 +0100Sgeo(~Sgeo@user/sgeo) Sgeo
2024-11-14 00:53:24 +0100alp(~alp@2001:861:e3d6:8f80:cd0a:c39d:37b7:c1a3) (Remote host closed the connection)
2024-11-14 00:54:14 +0100alp(~alp@2001:861:e3d6:8f80:c1d0:6a01:957c:3af2)
2024-11-14 00:55:56 +0100alp(~alp@2001:861:e3d6:8f80:c1d0:6a01:957c:3af2) (Remote host closed the connection)
2024-11-14 01:01:19 +0100falafel(~falafel@2600:1700:99f4:2050:41b3:d17e:817a:4e83) (Ping timeout: 260 seconds)
2024-11-14 01:10:06 +0100acidjnk_new3(~acidjnk@p200300d6e7283f717cba866c0fa9f7cd.dip0.t-ipconnect.de) (Read error: Connection reset by peer)
2024-11-14 01:10:17 +0100alexherbo2(~alexherbo@2a02-8440-3117-f07c-987b-fc29-77ee-addd.rev.sfr.net) alexherbo2
2024-11-14 01:11:02 +0100 <Leary> jackdk: I doubt there's anything like an 'idiom' for this. Does `class HasField f r (Field f r) => HasFieldF f r where { type Field f r }; instance HasField f r t => HasFieldF f r where { type Field f r = t }` work?
2024-11-14 01:14:53 +0100Tuplanolla(~Tuplanoll@91-159-69-59.elisa-laajakaista.fi) (Quit: Leaving.)
2024-11-14 01:16:38 +0100Lord_of_Life(~Lord@user/lord-of-life/x-2819915) (Ping timeout: 245 seconds)
2024-11-14 01:17:43 +0100 <glguy> jackdk: You could do something like this: https://bpa.st/AYDQ
2024-11-14 01:18:38 +0100Lord_of_Life(~Lord@user/lord-of-life/x-2819915) Lord_of_Life
2024-11-14 01:20:20 +0100arahael(~arahael@user/arahael) (Quit: Lost terminal)
2024-11-14 01:25:58 +0100sprotte24(~sprotte24@p200300d16f059400e8d39b8ffa006815.dip0.t-ipconnect.de) (Quit: Leaving)
2024-11-14 01:26:14 +0100xff0x(~xff0x@2405:6580:b080:900:ca42:e655:d7e4:ec2b) (Ping timeout: 272 seconds)
2024-11-14 01:32:10 +0100peterbecich(~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 252 seconds)
2024-11-14 01:35:18 +0100 <jackdk> Leary: alas no: "The RHS of an associated type declaration mentions out-of-scope variable ‘t’ All such variables must be bound on the LHS"; glguy: Yeah, recursing through the `Rep` seems like the best bet. Thanks to you both.
2024-11-14 01:36:34 +0100MironZ3(~MironZ@nat-infra.ehlab.uk) (Quit: Ping timeout (120 seconds))
2024-11-14 01:36:34 +0100Square(~Square@user/square) Square
2024-11-14 01:39:10 +0100tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Read error: Connection reset by peer)
2024-11-14 01:43:55 +0100MironZ3(~MironZ@nat-infra.ehlab.uk)
2024-11-14 01:44:15 +0100ljdarj1(~Thunderbi@user/ljdarj) ljdarj
2024-11-14 01:47:34 +0100ljdarj(~Thunderbi@user/ljdarj) (Ping timeout: 265 seconds)
2024-11-14 01:47:34 +0100ljdarj1ljdarj
2024-11-14 01:48:46 +0100athostFI(~Atte@176-93-56-50.bb.dnainternet.fi) (Read error: Connection reset by peer)
2024-11-14 01:49:48 +0100 <jle`> does anybody know if there has been any updates on https://github.com/haskell/cabal/issues/9577 ? is there a good way to get haddock to do multiple sublibraries?
2024-11-14 01:50:03 +0100 <glguy> getting ready for aoc? ;-)
2024-11-14 01:51:19 +0100 <geekosaur> https://github.com/haskell/cabal/pull/9821 maybe?
2024-11-14 01:51:52 +0100 <jle`> glguy: heh how did you guess
2024-11-14 01:52:04 +0100 <jle`> i am merging all of my aoc libs into a single master cabal project
2024-11-14 01:52:14 +0100 <glguy> jle`: I can't think of any other reason to use multiple sublibraries ^_^
2024-11-14 01:52:38 +0100 <geekosaur> amazonka and recent HLS use them
2024-11-14 01:52:59 +0100 <geekosaur> HLS for all its plugins, amazonka for all its generated service packages
2024-11-14 01:53:06 +0100 <glguy> geekosaur: Maybe someone used those libraries to solve an aoc problem then
2024-11-14 01:53:09 +0100 <Leary> jle`: There's some discussion on it here: https://discourse.haskell.org/t/best-practices-for-public-cabal-sublibraries/10272
2024-11-14 01:53:26 +0100 <jle`> geekosaur: ah that does seem promising, do you know if it's in any cabal releases?
2024-11-14 01:54:06 +0100 <geekosaur> not yet but it should be in 3.14.1.0
2024-11-14 01:54:16 +0100 <geekosaur> which is due around when ghc 9.12.1 GA is
2024-11-14 01:54:32 +0100 <jle`> ooh, that's in a matter of days right?
2024-11-14 01:54:36 +0100 <geekosaur> the release process has already begun
2024-11-14 01:54:47 +0100 <jle`> woo hoo
2024-11-14 01:55:19 +0100 <jle`> rate of cabal improvements has been amazing
2024-11-14 02:14:21 +0100peterbecich(~Thunderbi@syn-047-229-123-186.res.spectrum.com) peterbecich
2024-11-14 02:18:56 +0100xff0x(~xff0x@fsb6a9491c.tkyc517.ap.nuro.jp)
2024-11-14 02:21:07 +0100ljdarj(~Thunderbi@user/ljdarj) (Quit: ljdarj)
2024-11-14 02:27:07 +0100CrunchyFlakes_(~CrunchyFl@ip1f13e94e.dynamic.kabel-deutschland.de) (Ping timeout: 264 seconds)
2024-11-14 02:28:51 +0100yin(~z@user/zero) (Read error: Connection reset by peer)
2024-11-14 02:29:30 +0100zero(~z@user/zero) zero
2024-11-14 02:33:06 +0100califax(~califax@user/califx) (Remote host closed the connection)
2024-11-14 02:43:43 +0100califax(~califax@user/califx) califx
2024-11-14 02:45:51 +0100jero98772(~jero98772@190.158.28.32)
2024-11-14 02:47:45 +0100telser(~quassel@user/telser) (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.)
2024-11-14 02:55:16 +0100jero98772(~jero98772@190.158.28.32) (Ping timeout: 244 seconds)
2024-11-14 03:00:23 +0100housemate(~housemate@146.70.66.228) (Quit: "I saw it in a tiktok video and thought that it was the most smartest answer ever." ~ AnonOps Radio [some time some place] | I AM THE DERIVATIVE I AM GOING TANGENT TO THE CURVE!)
2024-11-14 03:13:26 +0100Smiles(uid551636@id-551636.lymington.irccloud.com) Smiles
2024-11-14 03:14:45 +0100machinedgod(~machinedg@d108-173-18-100.abhsia.telus.net) (Ping timeout: 246 seconds)
2024-11-14 03:30:17 +0100myxos(~myxos@syn-065-028-251-121.res.spectrum.com) myxokephale
2024-11-14 04:06:25 +0100alexherbo2(~alexherbo@2a02-8440-3117-f07c-987b-fc29-77ee-addd.rev.sfr.net) (Remote host closed the connection)
2024-11-14 04:13:00 +0100arahael(~arahael@user/arahael) arahael
2024-11-14 04:16:04 +0100arahael_(~arahael@user/arahael) arahael
2024-11-14 04:29:59 +0100td_(~td@i53870901.versanet.de) (Ping timeout: 260 seconds)
2024-11-14 04:31:21 +0100td_(~td@i5387092A.versanet.de) td_
2024-11-14 04:46:17 +0100Pozyomka(~pyon@user/pyon) (Quit: Reboot.)
2024-11-14 04:52:54 +0100agent314(~quassel@static-198-44-129-53.cust.tzulo.com) agent314
2024-11-14 05:09:25 +0100bitdex(~bitdex@gateway/tor-sasl/bitdex) bitdex
2024-11-14 05:10:33 +0100agent314(~quassel@static-198-44-129-53.cust.tzulo.com) (Ping timeout: 276 seconds)
2024-11-14 05:12:25 +0100divya(~user@139.5.11.223) divya
2024-11-14 05:19:01 +0100mange(~user@user/mange) mange
2024-11-14 05:19:01 +0100mange(~user@user/mange) (Excess Flood)
2024-11-14 05:25:13 +0100mc47(~mc47@xmonad/TheMC47) (Remote host closed the connection)
2024-11-14 05:25:33 +0100mc47(~mc47@xmonad/TheMC47) mc47
2024-11-14 05:27:30 +0100divya(~user@139.5.11.223) (Remote host closed the connection)
2024-11-14 05:30:03 +0100Pozyomka(~pyon@user/pyon) pyon
2024-11-14 05:30:40 +0100mange(~user@user/mange) mange
2024-11-14 05:31:26 +0100mange(~user@user/mange) (Client Quit)
2024-11-14 05:32:37 +0100pavonia(~user@user/siracusa) (Quit: Bye!)
2024-11-14 05:36:48 +0100housemate(~housemate@146.70.66.228) housemate
2024-11-14 05:37:01 +0100stiell_(~stiell@gateway/tor-sasl/stiell) (Ping timeout: 260 seconds)
2024-11-14 05:41:15 +0100stiell_(~stiell@gateway/tor-sasl/stiell) stiell
2024-11-14 05:54:07 +0100vanishingideal(~vanishing@user/vanishingideal) vanishingideal
2024-11-14 06:06:35 +0100mikko(~mikko@user/mikko) (Ping timeout: 255 seconds)
2024-11-14 06:13:50 +0100agent314(~quassel@static-198-44-129-53.cust.tzulo.com) agent314
2024-11-14 06:14:44 +0100visilii_(~visilii@213.24.127.47)
2024-11-14 06:14:54 +0100visilii(~visilii@213.24.133.209) (Ping timeout: 276 seconds)
2024-11-14 06:36:59 +0100Guest16(~Guest16@2401:4900:65c9:bca3:883d:d42c:cc19:7f95)
2024-11-14 06:37:48 +0100 <Guest16> hi
2024-11-14 06:37:56 +0100 <Guest16> Does anyone know why http://wiki.haskell.org/ is down
2024-11-14 06:39:54 +0100 <Axman6> There's been issues with the machine it runs on lately, which I believe are proving to be quite hard to fix. sm I think knows more (there's also #haskell-infrastructure)
2024-11-14 06:41:03 +0100 <probie> Guest16: https://mail.haskell.org/pipermail/haskell-cafe/2024-November/136929.html
2024-11-14 06:41:44 +0100 <Guest16> thank you
2024-11-14 06:52:22 +0100peterbecich(~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Remote host closed the connection)
2024-11-14 06:52:41 +0100Guest16(~Guest16@2401:4900:65c9:bca3:883d:d42c:cc19:7f95) (Quit: Client closed)
2024-11-14 06:58:06 +0100takuan(~takuan@178-116-218-225.access.telenet.be)
2024-11-14 07:00:42 +0100 <haskellbridge> <sm> https://github.com/haskell/haskell-wiki-configuration/issues/43
2024-11-14 07:02:55 +0100misterfish(~misterfis@84.53.85.146) misterfish
2024-11-14 07:04:06 +0100michalz(~michalz@185.246.207.203)
2024-11-14 07:08:06 +0100philopsos(~caecilius@user/philopsos) (Quit: Lost terminal)
2024-11-14 07:08:12 +0100peterbecich(~Thunderbi@syn-047-229-123-186.res.spectrum.com) peterbecich
2024-11-14 07:12:25 +0100Smiles(uid551636@id-551636.lymington.irccloud.com) (Quit: Connection closed for inactivity)
2024-11-14 07:16:45 +0100Square(~Square@user/square) (Remote host closed the connection)
2024-11-14 07:17:09 +0100Square(~Square@user/square) Square
2024-11-14 07:25:25 +0100peterbecich(~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 248 seconds)
2024-11-14 07:31:18 +0100Square2(~Square4@user/square) Square
2024-11-14 07:34:04 +0100Square(~Square@user/square) (Ping timeout: 252 seconds)
2024-11-14 07:51:43 +0100alp(~alp@2001:861:e3d6:8f80:c4b2:beb0:f361:d694)
2024-11-14 07:57:54 +0100hellwolf(~user@0e2f-3a3b-aecf-adb3-0f00-4d40-07d0-2001.sta.estpak.ee) (Ping timeout: 246 seconds)
2024-11-14 07:58:37 +0100divya(~user@139.5.11.223) divya
2024-11-14 07:59:20 +0100divya(~user@139.5.11.223) (Quit: ERC 5.6.0.30.1 (IRC client for GNU Emacs 30.0.91))
2024-11-14 08:00:12 +0100divya(~user@139.5.11.223) divya
2024-11-14 08:00:12 +0100tv(~tv@user/tv) (Read error: Connection reset by peer)
2024-11-14 08:06:51 +0100Sgeo(~Sgeo@user/sgeo) (Read error: Connection reset by peer)
2024-11-14 08:09:38 +0100Xe(~cadey@perl/impostor/xe) (Ping timeout: 248 seconds)
2024-11-14 08:09:59 +0100Xe_(~Xe@perl/impostor/xe) (Ping timeout: 252 seconds)
2024-11-14 08:16:08 +0100Xe(~Xe@perl/impostor/xe) Xe
2024-11-14 08:17:18 +0100Cadey(~cadey@perl/impostor/xe) Xe
2024-11-14 08:30:14 +0100acidjnk(~acidjnk@p200300d6e7283f73687bc11ede7922f8.dip0.t-ipconnect.de) acidjnk
2024-11-14 08:34:21 +0100petrichor(~znc-user@user/petrichor) petrichor
2024-11-14 08:45:10 +0100vanishingideal(~vanishing@user/vanishingideal) (Ping timeout: 265 seconds)
2024-11-14 08:45:17 +0100ubert(~Thunderbi@178.165.164.236.wireless.dyn.drei.com) ubert
2024-11-14 08:51:11 +0100ft(~ft@p4fc2a216.dip0.t-ipconnect.de) (Quit: leaving)
2024-11-14 08:51:35 +0100vanishingideal(~vanishing@user/vanishingideal) vanishingideal
2024-11-14 08:51:46 +0100lortabac(~lortabac@2a01:e0a:541:b8f0:55ab:e185:7f81:54a4) lortabac
2024-11-14 08:53:54 +0100kuribas(~user@2a02:1808:84:5008:bc1f:a609:eab5:5cb9) kuribas
2024-11-14 08:55:57 +0100ubert(~Thunderbi@178.165.164.236.wireless.dyn.drei.com) (Quit: ubert)
2024-11-14 08:58:52 +0100kuribas(~user@2a02:1808:84:5008:bc1f:a609:eab5:5cb9) (Remote host closed the connection)
2024-11-14 08:59:05 +0100kuribas(~user@2a02:1808:84:5008:61f:fb32:d5a4:cce1) kuribas
2024-11-14 09:00:02 +0100caconym(~caconym@user/caconym) (Quit: bye)
2024-11-14 09:00:39 +0100caconym(~caconym@user/caconym) caconym
2024-11-14 09:01:47 +0100kuribas`(~user@ip-188-118-57-242.reverse.destiny.be) kuribas
2024-11-14 09:03:43 +0100kuribas(~user@2a02:1808:84:5008:61f:fb32:d5a4:cce1) (Ping timeout: 264 seconds)
2024-11-14 09:08:39 +0100vanishingideal(~vanishing@user/vanishingideal) (Ping timeout: 252 seconds)
2024-11-14 09:10:24 +0100vanishingideal(~vanishing@user/vanishingideal) vanishingideal
2024-11-14 09:16:00 +0100falafel(~falafel@2600:1700:99f4:2050:1cad:26ba:1279:135d) falafel
2024-11-14 09:16:18 +0100tv(~tv@user/tv) tv
2024-11-14 09:22:38 +0100mceresa(~mceresa@user/mceresa) (Remote host closed the connection)
2024-11-14 09:22:47 +0100mceresa(~mceresa@user/mceresa) mceresa
2024-11-14 09:25:02 +0100misterfish(~misterfis@84.53.85.146) (Ping timeout: 255 seconds)
2024-11-14 09:27:15 +0100Smiles(uid551636@id-551636.lymington.irccloud.com) Smiles
2024-11-14 09:38:42 +0100falafel(~falafel@2600:1700:99f4:2050:1cad:26ba:1279:135d) (Remote host closed the connection)
2024-11-14 09:51:18 +0100hellwolf(~user@2001:1530:70:545:809e:22e1:baa3:1e4c) hellwolf
2024-11-14 09:58:59 +0100machinedgod(~machinedg@d108-173-18-100.abhsia.telus.net) machinedgod
2024-11-14 10:02:51 +0100alphazone(~alphazone@2.219.56.221) (Ping timeout: 246 seconds)
2024-11-14 10:05:57 +0100Maxdamantus(~Maxdamant@user/maxdamantus) (Ping timeout: 248 seconds)
2024-11-14 10:08:06 +0100rvalue(~rvalue@user/rvalue) (Read error: Connection reset by peer)
2024-11-14 10:08:36 +0100rvalue(~rvalue@user/rvalue) rvalue
2024-11-14 10:13:18 +0100misterfish(~misterfis@31-161-39-137.biz.kpn.net) misterfish
2024-11-14 10:14:38 +0100CrunchyFlakes(~CrunchyFl@ip1f13e94e.dynamic.kabel-deutschland.de)
2024-11-14 10:19:37 +0100Maxdamantus(~Maxdamant@user/maxdamantus) Maxdamantus
2024-11-14 10:24:45 +0100vanishingideal(~vanishing@user/vanishingideal) (Quit: leaving)
2024-11-14 10:31:28 +0100chele(~chele@user/chele) chele
2024-11-14 10:32:08 +0100alp(~alp@2001:861:e3d6:8f80:c4b2:beb0:f361:d694) (Remote host closed the connection)
2024-11-14 10:32:14 +0100tzh(~tzh@c-76-115-131-146.hsd1.or.comcast.net) (Quit: zzz)
2024-11-14 10:32:25 +0100alp(~alp@2001:861:e3d6:8f80:c18:bc99:f25e:38cc)
2024-11-14 10:41:23 +0100tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl)
2024-11-14 10:42:06 +0100favalex(~favalex@176.200.207.41)
2024-11-14 10:50:16 +0100mari-estel(~mari-este@user/mari-estel) mari-estel
2024-11-14 10:53:06 +0100favalex(~favalex@176.200.207.41) (Quit: Client closed)
2024-11-14 11:05:52 +0100mari18976(~mari-este@user/mari-estel) mari-estel
2024-11-14 11:07:14 +0100hgolden(~hgolden@2603:8000:9d00:3ed1:6c70:1ac0:d127:74dd) (Ping timeout: 260 seconds)
2024-11-14 11:08:17 +0100mari-estel(~mari-este@user/mari-estel) (Ping timeout: 248 seconds)
2024-11-14 11:10:27 +0100mari-estel(~mari-este@user/mari-estel) mari-estel
2024-11-14 11:10:45 +0100mari18976(~mari-este@user/mari-estel) (Read error: Connection reset by peer)
2024-11-14 11:12:07 +0100mari24610(~mari-este@user/mari-estel) mari-estel
2024-11-14 11:14:04 +0100lxsameer(~lxsameer@Serene/lxsameer) lxsameer
2024-11-14 11:15:10 +0100xff0x(~xff0x@fsb6a9491c.tkyc517.ap.nuro.jp) (Ping timeout: 252 seconds)
2024-11-14 11:15:12 +0100mari-estel(~mari-este@user/mari-estel) (Ping timeout: 276 seconds)
2024-11-14 11:20:44 +0100mari-estel(~mari-este@user/mari-estel) mari-estel
2024-11-14 11:23:39 +0100mari24610(~mari-este@user/mari-estel) (Ping timeout: 276 seconds)
2024-11-14 11:24:27 +0100ash3en(~Thunderbi@149.222.147.110) ash3en
2024-11-14 11:27:17 +0100Digitteknohippie(~user@user/digit) Digit
2024-11-14 11:27:49 +0100Digit(~user@user/digit) (Ping timeout: 260 seconds)
2024-11-14 11:28:05 +0100ash3en(~Thunderbi@149.222.147.110) (Client Quit)
2024-11-14 11:32:25 +0100Smiles(uid551636@id-551636.lymington.irccloud.com) (Quit: Connection closed for inactivity)
2024-11-14 11:33:37 +0100DigitteknohippieDigit
2024-11-14 11:49:20 +0100mikko(~mikko@user/mikko) mikko
2024-11-14 11:57:08 +0100mari-estel(~mari-este@user/mari-estel) (Remote host closed the connection)
2024-11-14 11:57:18 +0100mari-estel(~mari-este@user/mari-estel) mari-estel
2024-11-14 11:58:42 +0100mari-estel(~mari-este@user/mari-estel) (Remote host closed the connection)
2024-11-14 11:58:53 +0100mari-estel(~mari-este@user/mari-estel) mari-estel
2024-11-14 12:00:01 +0100Smiles(uid551636@id-551636.lymington.irccloud.com) Smiles
2024-11-14 12:05:29 +0100mari96334(~mari-este@user/mari-estel) mari-estel
2024-11-14 12:06:53 +0100mari96334(~mari-este@user/mari-estel) (Remote host closed the connection)
2024-11-14 12:07:05 +0100mari89179(~mari-este@user/mari-estel) mari-estel
2024-11-14 12:07:42 +0100mari-estel(~mari-este@user/mari-estel) (Ping timeout: 252 seconds)
2024-11-14 12:11:27 +0100xff0x(~xff0x@ai080132.d.east.v6connect.net)
2024-11-14 12:22:06 +0100jero98772(~jero98772@190.158.28.32)
2024-11-14 12:26:32 +0100__monty__(~toonn@user/toonn) toonn
2024-11-14 12:38:40 +0100mari-estel(~mari-este@user/mari-estel) mari-estel
2024-11-14 12:40:42 +0100mari89179(~mari-este@user/mari-estel) (Ping timeout: 252 seconds)
2024-11-14 12:42:19 +0100mari29333(~mari-este@user/mari-estel) mari-estel
2024-11-14 12:43:13 +0100mari-estel(~mari-este@user/mari-estel) (Read error: Connection reset by peer)
2024-11-14 12:43:53 +0100mari-estel(~mari-este@user/mari-estel) mari-estel
2024-11-14 12:46:03 +0100mari-estel(~mari-este@user/mari-estel) (Client Quit)
2024-11-14 12:47:34 +0100mari29333(~mari-este@user/mari-estel) (Ping timeout: 260 seconds)
2024-11-14 12:52:05 +0100pavonia(~user@user/siracusa) siracusa
2024-11-14 12:57:24 +0100 <hellwolf> Is "IOPhobia" pathological case? After decades of programming, I find pure joy in writing main part of the code that deals with zero IO. And only Haskell can guarantee that, to the extent that I am questioning if I am sick.
2024-11-14 12:58:54 +0100jero98772(~jero98772@190.158.28.32) (Remote host closed the connection)
2024-11-14 13:00:04 +0100caconym(~caconym@user/caconym) (Quit: bye)
2024-11-14 13:01:18 +0100 <Rembane> hellwolf: Nah, it's sound. Not having to deal with side effects makes code so much easier to write, read and test.
2024-11-14 13:02:11 +0100caconym(~caconym@user/caconym) caconym
2024-11-14 13:03:23 +0100 <hellwolf> I hesitate to make a connetion with germophobia, since I personally am an opposite of a germophobia.
2024-11-14 13:04:00 +0100 <Leary> hellwolf: Welcome to the oasis of sanity.
2024-11-14 13:04:09 +0100 <Rembane> Some germs are quite good to not be in contact with IMO
2024-11-14 13:05:28 +0100 <hellwolf> like unsafePerformIO?
2024-11-14 13:07:45 +0100acidjnk(~acidjnk@p200300d6e7283f73687bc11ede7922f8.dip0.t-ipconnect.de) (Ping timeout: 248 seconds)
2024-11-14 13:09:11 +0100misterfish(~misterfis@31-161-39-137.biz.kpn.net) (Ping timeout: 252 seconds)
2024-11-14 13:09:23 +0100mari-estel(~mari-este@user/mari-estel) mari-estel
2024-11-14 13:13:49 +0100 <dminuoso> unsafePerformIO is indeed quite unsafe. :-)
2024-11-14 13:16:33 +0100hellwolflike when label is truth for to itself.
2024-11-14 13:17:57 +0100 <dminuoso> It was a simple case of something like `replicate n (unsafePerformIO (newIORef []))`, which GHC happily refactored into `let x = unsafePerformIO (newIORef []) in replicate n x`
2024-11-14 13:18:14 +0100housemate(~housemate@146.70.66.228) (Quit: "I saw it in a tiktok video and thought that it was the most smartest answer ever." ~ AnonOps Radio [some time some place] | I AM THE DERIVATIVE I AM GOING TANGENT TO THE CURVE!)
2024-11-14 13:18:15 +0100 <dminuoso> (In reality the code was far more sophisticated, so it was neither obvious how or why this happened)
2024-11-14 13:18:46 +0100 <dminuoso> I mean actually there was a `traverse_` in there too.
2024-11-14 13:19:48 +0100 <dminuoso> Yeah I think it was something like `unsafePerformIO (traverse_ (\_ -> newIORef []) xs)` and GHC successfully floated that IORef out
2024-11-14 13:20:06 +0100 <dminuoso> Ill have to dig through the commit history to find this one.
2024-11-14 13:20:14 +0100 <hellwolf> which code base?
2024-11-14 13:20:26 +0100 <dminuoso> An internal compiler of ours.
2024-11-14 13:20:32 +0100 <dminuoso> No, those examples I named are both wrong. Mmm.
2024-11-14 13:22:02 +0100 <dminuoso> hellwolf: Anyway, IO can still be a useful tool, especially if you want any kind of introspectability of whats going on (say logging or debugging)
2024-11-14 13:22:21 +0100 <dminuoso> Pure code is often cumbersome to debug
2024-11-14 13:22:42 +0100 <dminuoso> Consider something like GHC, where large portions work in IO
2024-11-14 13:23:59 +0100mari59415(~mari-este@user/mari-estel) mari-estel
2024-11-14 13:24:25 +0100arahael_(~arahael@user/arahael) (Quit: leaving)
2024-11-14 13:25:23 +0100arahael_(~arahael@user/arahael) arahael
2024-11-14 13:26:03 +0100mari-estel(~mari-este@user/mari-estel) (Ping timeout: 252 seconds)
2024-11-14 13:26:39 +0100tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…)
2024-11-14 13:27:19 +0100 <hellwolf> runTrace your_pure_fn your_trace_filters ...currying your_pure_fn_args...
2024-11-14 13:28:06 +0100 <dminuoso> What is `runTrace` supposed to be here?
2024-11-14 13:28:25 +0100 <hellwolf> that'd be my ideal way of trace into your pure fn in a principled way. I am entirely sure how feasible/difficult it could be; I did somethings that involve some aspects of such a thing.
2024-11-14 13:28:32 +0100misterfish(~misterfis@31-161-39-137.biz.kpn.net) misterfish
2024-11-14 13:28:48 +0100 <hellwolf> sorry, typed too slow. I meant to propose a hypothetical
2024-11-14 13:31:46 +0100haskellbridge(~hackager@syn-024-093-192-219.res.spectrum.com) (Remote host closed the connection)
2024-11-14 13:31:51 +0100 <lortabac> "Pure code is often cumbersome to debug" *with GHC*
2024-11-14 13:32:28 +0100 <lortabac> I don't think we should see lack of observability as an intrinsic property of pure computations
2024-11-14 13:32:36 +0100haskellbridge(~hackager@syn-024-093-192-219.res.spectrum.com) hackager
2024-11-14 13:32:36 +0100ChanServ+v haskellbridge
2024-11-14 13:32:42 +0100 <mari59415> no mentions about pure code being amounts easier to test
2024-11-14 13:33:53 +0100 <hellwolf> But I find the habit of spending more time in thinking then examining into what happened is a better use of time. Of course, on the contrary, Linus, notoriously, promoted the idea of printf debugging. So I guess the tool influence on how you do troubleshooting.
2024-11-14 13:34:38 +0100 <hellwolf> exactly, mari59415, it is a problem most applicable to impure code. For pure code, you write properties (which means thinking a lot about what you are writing.)
2024-11-14 13:35:34 +0100mari-estel(~mari-este@user/mari-estel) mari-estel
2024-11-14 13:36:10 +0100 <hellwolf> fwiw, @dminuoso, I had a small example here https://discourse.haskell.org/t/variable-arity-currying-helper/10659 that decorates "let foo' = curry' (MkFn foo)" but that assumes all arguments is "showable". to make it runTrace, you'd need to have a default instance for all types, and then overlapping instance for Show, Num, Functor, etc.
2024-11-14 13:37:49 +0100mari59415(~mari-este@user/mari-estel) (Read error: Connection reset by peer)
2024-11-14 13:38:40 +0100 <mari-estel> huh properties help equally with pure and monadic
2024-11-14 13:38:40 +0100 <mari-estel> prints or traces are a good way to collect test samples while troubleshooting
2024-11-14 13:41:35 +0100 <hellwolf> Does Trace.trace help?
2024-11-14 13:41:53 +0100 <hellwolf> Debug.Trace (trace)
2024-11-14 13:43:13 +0100mari73904(~mari-este@user/mari-estel) mari-estel
2024-11-14 13:44:19 +0100mari-estel(~mari-este@user/mari-estel) (Read error: Connection reset by peer)
2024-11-14 13:44:51 +0100mari-estel(~mari-este@user/mari-estel) mari-estel
2024-11-14 13:45:55 +0100 <kuribas`> The problem is that the GHC debugger follow the imperative model for debugging (stepping through, etc..)
2024-11-14 13:46:10 +0100 <kuribas`> A more useful pure debugger would allow you to choose which expression to evaluate.
2024-11-14 13:46:40 +0100 <kuribas`> I the end, lazyness doesn't specify an order for execution.
2024-11-14 13:47:00 +0100 <kuribas`> As long as the semantics are preserved.
2024-11-14 13:47:01 +0100mari-estel(~mari-este@user/mari-estel) (Client Quit)
2024-11-14 13:47:50 +0100mari73904(~mari-este@user/mari-estel) (Ping timeout: 255 seconds)
2024-11-14 13:48:41 +0100 <__monty__> That would also cause confusion though. Since sometimes referential transparency is a lie. And it's easy to convince yourself that the expressions must surely be evaluating in the order you think they are.
2024-11-14 13:58:57 +0100 <kuribas`> __monty__: how can it be a lie with "pure" code?
2024-11-14 13:59:08 +0100 <kuribas`> Assuming it doesn't use unsafePerformIO.
2024-11-14 13:59:51 +0100alphazone(~alphazone@2.219.56.221)
2024-11-14 14:02:26 +0100 <__monty__> There's the rub : )
2024-11-14 14:05:11 +0100 <haskellbridge> <hellwolf> the lie is limited to the extent that, if your program is not total, would the debugger hurt your bottom where you intend to leave it so.
2024-11-14 14:12:04 +0100 <kuribas`> > head [1, undefined]
2024-11-14 14:12:05 +0100 <lambdabot> 1
2024-11-14 14:12:30 +0100 <kuribas`> If you would evaluate the second element of the list, the debugger should not halt the whole expression.
2024-11-14 14:13:44 +0100 <bailsman> Huh, are mutable vectors a scam? `VM.iforM_ mv $ \i x -> VM.write mv i (updateValue x)` is considerably slower for simple objects, and barely faster than `map updateValue` even for large complex objects.
2024-11-14 14:14:28 +0100 <geekosaur> they will definitely have costs you don't incur with immutable vectors
2024-11-14 14:15:25 +0100 <bailsman> So the use cases are considerably more niche than I thought. Like if you need to exchange two elements or something, the pure version would have to copy the entire thing and the mutable version only two elements. But for most cases, it's a bait?