| 2024-11-14 00:01:51 +0100 | falafel | (~falafel@2600:1700:99f4:2050:41b3:d17e:817a:4e83) falafel |
| 2024-11-14 00:02:55 +0100 | Everything | (~Everythin@46.211.104.82) (Quit: leaving) |
| 2024-11-14 00:28:22 +0100 | Xe_ | (~Xe@perl/impostor/xe) Xe |
| 2024-11-14 00:29:11 +0100 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) peterbecich |
| 2024-11-14 00:29:57 +0100 | acidjnk_new3 | (~acidjnk@p200300d6e7283f7100fa0b96aa6639bf.dip0.t-ipconnect.de) (Ping timeout: 248 seconds) |
| 2024-11-14 00:32:33 +0100 | acidjnk_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 +0100 | alexherbo2 | (~alexherbo@2a02-8440-3117-f07c-987b-fc29-77ee-addd.rev.sfr.net) (Remote host closed the connection) |
| 2024-11-14 00:49:22 +0100 | CoolMa7 | (~CoolMa7@ip5f5b8957.dynamic.kabel-deutschland.de) (Quit: My Mac has gone to sleep. ZZZzzz…) |
| 2024-11-14 00:49:54 +0100 | athostFI | (~Atte@176-93-56-50.bb.dnainternet.fi) |
| 2024-11-14 00:50:52 +0100 | alp | (~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 +0100 | alp | (~alp@2001:861:e3d6:8f80:cd0a:c39d:37b7:c1a3) |
| 2024-11-14 00:53:05 +0100 | Sgeo | (~Sgeo@user/sgeo) Sgeo |
| 2024-11-14 00:53:24 +0100 | alp | (~alp@2001:861:e3d6:8f80:cd0a:c39d:37b7:c1a3) (Remote host closed the connection) |
| 2024-11-14 00:54:14 +0100 | alp | (~alp@2001:861:e3d6:8f80:c1d0:6a01:957c:3af2) |
| 2024-11-14 00:55:56 +0100 | alp | (~alp@2001:861:e3d6:8f80:c1d0:6a01:957c:3af2) (Remote host closed the connection) |
| 2024-11-14 01:01:19 +0100 | falafel | (~falafel@2600:1700:99f4:2050:41b3:d17e:817a:4e83) (Ping timeout: 260 seconds) |
| 2024-11-14 01:10:06 +0100 | acidjnk_new3 | (~acidjnk@p200300d6e7283f717cba866c0fa9f7cd.dip0.t-ipconnect.de) (Read error: Connection reset by peer) |
| 2024-11-14 01:10:17 +0100 | alexherbo2 | (~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 +0100 | Tuplanolla | (~Tuplanoll@91-159-69-59.elisa-laajakaista.fi) (Quit: Leaving.) |
| 2024-11-14 01:16:38 +0100 | Lord_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 +0100 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) Lord_of_Life |
| 2024-11-14 01:20:20 +0100 | arahael | (~arahael@user/arahael) (Quit: Lost terminal) |
| 2024-11-14 01:25:58 +0100 | sprotte24 | (~sprotte24@p200300d16f059400e8d39b8ffa006815.dip0.t-ipconnect.de) (Quit: Leaving) |
| 2024-11-14 01:26:14 +0100 | xff0x | (~xff0x@2405:6580:b080:900:ca42:e655:d7e4:ec2b) (Ping timeout: 272 seconds) |
| 2024-11-14 01:32:10 +0100 | peterbecich | (~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 +0100 | MironZ3 | (~MironZ@nat-infra.ehlab.uk) (Quit: Ping timeout (120 seconds)) |
| 2024-11-14 01:36:34 +0100 | Square | (~Square@user/square) Square |
| 2024-11-14 01:39:10 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Read error: Connection reset by peer) |
| 2024-11-14 01:43:55 +0100 | MironZ3 | (~MironZ@nat-infra.ehlab.uk) |
| 2024-11-14 01:44:15 +0100 | ljdarj1 | (~Thunderbi@user/ljdarj) ljdarj |
| 2024-11-14 01:47:34 +0100 | ljdarj | (~Thunderbi@user/ljdarj) (Ping timeout: 265 seconds) |
| 2024-11-14 01:47:34 +0100 | ljdarj1 | ljdarj |
| 2024-11-14 01:48:46 +0100 | athostFI | (~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 +0100 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) peterbecich |
| 2024-11-14 02:18:56 +0100 | xff0x | (~xff0x@fsb6a9491c.tkyc517.ap.nuro.jp) |
| 2024-11-14 02:21:07 +0100 | ljdarj | (~Thunderbi@user/ljdarj) (Quit: ljdarj) |
| 2024-11-14 02:27:07 +0100 | CrunchyFlakes_ | (~CrunchyFl@ip1f13e94e.dynamic.kabel-deutschland.de) (Ping timeout: 264 seconds) |
| 2024-11-14 02:28:51 +0100 | yin | (~z@user/zero) (Read error: Connection reset by peer) |
| 2024-11-14 02:29:30 +0100 | zero | (~z@user/zero) zero |
| 2024-11-14 02:33:06 +0100 | califax | (~califax@user/califx) (Remote host closed the connection) |
| 2024-11-14 02:43:43 +0100 | califax | (~califax@user/califx) califx |
| 2024-11-14 02:45:51 +0100 | jero98772 | (~jero98772@190.158.28.32) |
| 2024-11-14 02:47:45 +0100 | telser | (~quassel@user/telser) (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) |
| 2024-11-14 02:55:16 +0100 | jero98772 | (~jero98772@190.158.28.32) (Ping timeout: 244 seconds) |
| 2024-11-14 03:00:23 +0100 | housemate | (~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 +0100 | Smiles | (uid551636@id-551636.lymington.irccloud.com) Smiles |
| 2024-11-14 03:14:45 +0100 | machinedgod | (~machinedg@d108-173-18-100.abhsia.telus.net) (Ping timeout: 246 seconds) |
| 2024-11-14 03:30:17 +0100 | myxos | (~myxos@syn-065-028-251-121.res.spectrum.com) myxokephale |
| 2024-11-14 04:06:25 +0100 | alexherbo2 | (~alexherbo@2a02-8440-3117-f07c-987b-fc29-77ee-addd.rev.sfr.net) (Remote host closed the connection) |
| 2024-11-14 04:13:00 +0100 | arahael | (~arahael@user/arahael) arahael |
| 2024-11-14 04:16:04 +0100 | arahael_ | (~arahael@user/arahael) arahael |
| 2024-11-14 04:29:59 +0100 | td_ | (~td@i53870901.versanet.de) (Ping timeout: 260 seconds) |
| 2024-11-14 04:31:21 +0100 | td_ | (~td@i5387092A.versanet.de) td_ |
| 2024-11-14 04:46:17 +0100 | Pozyomka | (~pyon@user/pyon) (Quit: Reboot.) |
| 2024-11-14 04:52:54 +0100 | agent314 | (~quassel@static-198-44-129-53.cust.tzulo.com) agent314 |
| 2024-11-14 05:09:25 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) bitdex |
| 2024-11-14 05:10:33 +0100 | agent314 | (~quassel@static-198-44-129-53.cust.tzulo.com) (Ping timeout: 276 seconds) |
| 2024-11-14 05:12:25 +0100 | divya | (~user@139.5.11.223) divya |
| 2024-11-14 05:19:01 +0100 | mange | (~user@user/mange) mange |
| 2024-11-14 05:19:01 +0100 | mange | (~user@user/mange) (Excess Flood) |
| 2024-11-14 05:25:13 +0100 | mc47 | (~mc47@xmonad/TheMC47) (Remote host closed the connection) |
| 2024-11-14 05:25:33 +0100 | mc47 | (~mc47@xmonad/TheMC47) mc47 |
| 2024-11-14 05:27:30 +0100 | divya | (~user@139.5.11.223) (Remote host closed the connection) |
| 2024-11-14 05:30:03 +0100 | Pozyomka | (~pyon@user/pyon) pyon |
| 2024-11-14 05:30:40 +0100 | mange | (~user@user/mange) mange |
| 2024-11-14 05:31:26 +0100 | mange | (~user@user/mange) (Client Quit) |
| 2024-11-14 05:32:37 +0100 | pavonia | (~user@user/siracusa) (Quit: Bye!) |
| 2024-11-14 05:36:48 +0100 | housemate | (~housemate@146.70.66.228) housemate |
| 2024-11-14 05:37:01 +0100 | stiell_ | (~stiell@gateway/tor-sasl/stiell) (Ping timeout: 260 seconds) |
| 2024-11-14 05:41:15 +0100 | stiell_ | (~stiell@gateway/tor-sasl/stiell) stiell |
| 2024-11-14 05:54:07 +0100 | vanishingideal | (~vanishing@user/vanishingideal) vanishingideal |
| 2024-11-14 06:06:35 +0100 | mikko | (~mikko@user/mikko) (Ping timeout: 255 seconds) |
| 2024-11-14 06:13:50 +0100 | agent314 | (~quassel@static-198-44-129-53.cust.tzulo.com) agent314 |
| 2024-11-14 06:14:44 +0100 | visilii_ | (~visilii@213.24.127.47) |
| 2024-11-14 06:14:54 +0100 | visilii | (~visilii@213.24.133.209) (Ping timeout: 276 seconds) |
| 2024-11-14 06:36:59 +0100 | Guest16 | (~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 +0100 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Remote host closed the connection) |
| 2024-11-14 06:52:41 +0100 | Guest16 | (~Guest16@2401:4900:65c9:bca3:883d:d42c:cc19:7f95) (Quit: Client closed) |
| 2024-11-14 06:58:06 +0100 | takuan | (~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 +0100 | misterfish | (~misterfis@84.53.85.146) misterfish |
| 2024-11-14 07:04:06 +0100 | michalz | (~michalz@185.246.207.203) |
| 2024-11-14 07:08:06 +0100 | philopsos | (~caecilius@user/philopsos) (Quit: Lost terminal) |
| 2024-11-14 07:08:12 +0100 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) peterbecich |
| 2024-11-14 07:12:25 +0100 | Smiles | (uid551636@id-551636.lymington.irccloud.com) (Quit: Connection closed for inactivity) |
| 2024-11-14 07:16:45 +0100 | Square | (~Square@user/square) (Remote host closed the connection) |
| 2024-11-14 07:17:09 +0100 | Square | (~Square@user/square) Square |
| 2024-11-14 07:25:25 +0100 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 248 seconds) |
| 2024-11-14 07:31:18 +0100 | Square2 | (~Square4@user/square) Square |
| 2024-11-14 07:34:04 +0100 | Square | (~Square@user/square) (Ping timeout: 252 seconds) |
| 2024-11-14 07:51:43 +0100 | alp | (~alp@2001:861:e3d6:8f80:c4b2:beb0:f361:d694) |
| 2024-11-14 07:57:54 +0100 | hellwolf | (~user@0e2f-3a3b-aecf-adb3-0f00-4d40-07d0-2001.sta.estpak.ee) (Ping timeout: 246 seconds) |
| 2024-11-14 07:58:37 +0100 | divya | (~user@139.5.11.223) divya |
| 2024-11-14 07:59:20 +0100 | divya | (~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 +0100 | divya | (~user@139.5.11.223) divya |
| 2024-11-14 08:00:12 +0100 | tv | (~tv@user/tv) (Read error: Connection reset by peer) |
| 2024-11-14 08:06:51 +0100 | Sgeo | (~Sgeo@user/sgeo) (Read error: Connection reset by peer) |
| 2024-11-14 08:09:38 +0100 | Xe | (~cadey@perl/impostor/xe) (Ping timeout: 248 seconds) |
| 2024-11-14 08:09:59 +0100 | Xe_ | (~Xe@perl/impostor/xe) (Ping timeout: 252 seconds) |
| 2024-11-14 08:16:08 +0100 | Xe | (~Xe@perl/impostor/xe) Xe |
| 2024-11-14 08:17:18 +0100 | Cadey | (~cadey@perl/impostor/xe) Xe |
| 2024-11-14 08:30:14 +0100 | acidjnk | (~acidjnk@p200300d6e7283f73687bc11ede7922f8.dip0.t-ipconnect.de) acidjnk |
| 2024-11-14 08:34:21 +0100 | petrichor | (~znc-user@user/petrichor) petrichor |
| 2024-11-14 08:45:10 +0100 | vanishingideal | (~vanishing@user/vanishingideal) (Ping timeout: 265 seconds) |
| 2024-11-14 08:45:17 +0100 | ubert | (~Thunderbi@178.165.164.236.wireless.dyn.drei.com) ubert |
| 2024-11-14 08:51:11 +0100 | ft | (~ft@p4fc2a216.dip0.t-ipconnect.de) (Quit: leaving) |
| 2024-11-14 08:51:35 +0100 | vanishingideal | (~vanishing@user/vanishingideal) vanishingideal |
| 2024-11-14 08:51:46 +0100 | lortabac | (~lortabac@2a01:e0a:541:b8f0:55ab:e185:7f81:54a4) lortabac |
| 2024-11-14 08:53:54 +0100 | kuribas | (~user@2a02:1808:84:5008:bc1f:a609:eab5:5cb9) kuribas |
| 2024-11-14 08:55:57 +0100 | ubert | (~Thunderbi@178.165.164.236.wireless.dyn.drei.com) (Quit: ubert) |
| 2024-11-14 08:58:52 +0100 | kuribas | (~user@2a02:1808:84:5008:bc1f:a609:eab5:5cb9) (Remote host closed the connection) |
| 2024-11-14 08:59:05 +0100 | kuribas | (~user@2a02:1808:84:5008:61f:fb32:d5a4:cce1) kuribas |
| 2024-11-14 09:00:02 +0100 | caconym | (~caconym@user/caconym) (Quit: bye) |
| 2024-11-14 09:00:39 +0100 | caconym | (~caconym@user/caconym) caconym |
| 2024-11-14 09:01:47 +0100 | kuribas` | (~user@ip-188-118-57-242.reverse.destiny.be) kuribas |
| 2024-11-14 09:03:43 +0100 | kuribas | (~user@2a02:1808:84:5008:61f:fb32:d5a4:cce1) (Ping timeout: 264 seconds) |
| 2024-11-14 09:08:39 +0100 | vanishingideal | (~vanishing@user/vanishingideal) (Ping timeout: 252 seconds) |
| 2024-11-14 09:10:24 +0100 | vanishingideal | (~vanishing@user/vanishingideal) vanishingideal |
| 2024-11-14 09:16:00 +0100 | falafel | (~falafel@2600:1700:99f4:2050:1cad:26ba:1279:135d) falafel |
| 2024-11-14 09:16:18 +0100 | tv | (~tv@user/tv) tv |
| 2024-11-14 09:22:38 +0100 | mceresa | (~mceresa@user/mceresa) (Remote host closed the connection) |
| 2024-11-14 09:22:47 +0100 | mceresa | (~mceresa@user/mceresa) mceresa |
| 2024-11-14 09:25:02 +0100 | misterfish | (~misterfis@84.53.85.146) (Ping timeout: 255 seconds) |
| 2024-11-14 09:27:15 +0100 | Smiles | (uid551636@id-551636.lymington.irccloud.com) Smiles |
| 2024-11-14 09:38:42 +0100 | falafel | (~falafel@2600:1700:99f4:2050:1cad:26ba:1279:135d) (Remote host closed the connection) |
| 2024-11-14 09:51:18 +0100 | hellwolf | (~user@2001:1530:70:545:809e:22e1:baa3:1e4c) hellwolf |
| 2024-11-14 09:58:59 +0100 | machinedgod | (~machinedg@d108-173-18-100.abhsia.telus.net) machinedgod |
| 2024-11-14 10:02:51 +0100 | alphazone | (~alphazone@2.219.56.221) (Ping timeout: 246 seconds) |
| 2024-11-14 10:05:57 +0100 | Maxdamantus | (~Maxdamant@user/maxdamantus) (Ping timeout: 248 seconds) |
| 2024-11-14 10:08:06 +0100 | rvalue | (~rvalue@user/rvalue) (Read error: Connection reset by peer) |
| 2024-11-14 10:08:36 +0100 | rvalue | (~rvalue@user/rvalue) rvalue |
| 2024-11-14 10:13:18 +0100 | misterfish | (~misterfis@31-161-39-137.biz.kpn.net) misterfish |
| 2024-11-14 10:14:38 +0100 | CrunchyFlakes | (~CrunchyFl@ip1f13e94e.dynamic.kabel-deutschland.de) |
| 2024-11-14 10:19:37 +0100 | Maxdamantus | (~Maxdamant@user/maxdamantus) Maxdamantus |
| 2024-11-14 10:24:45 +0100 | vanishingideal | (~vanishing@user/vanishingideal) (Quit: leaving) |
| 2024-11-14 10:31:28 +0100 | chele | (~chele@user/chele) chele |
| 2024-11-14 10:32:08 +0100 | alp | (~alp@2001:861:e3d6:8f80:c4b2:beb0:f361:d694) (Remote host closed the connection) |
| 2024-11-14 10:32:14 +0100 | tzh | (~tzh@c-76-115-131-146.hsd1.or.comcast.net) (Quit: zzz) |
| 2024-11-14 10:32:25 +0100 | alp | (~alp@2001:861:e3d6:8f80:c18:bc99:f25e:38cc) |
| 2024-11-14 10:41:23 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2024-11-14 10:42:06 +0100 | favalex | (~favalex@176.200.207.41) |
| 2024-11-14 10:50:16 +0100 | mari-estel | (~mari-este@user/mari-estel) mari-estel |
| 2024-11-14 10:53:06 +0100 | favalex | (~favalex@176.200.207.41) (Quit: Client closed) |
| 2024-11-14 11:05:52 +0100 | mari18976 | (~mari-este@user/mari-estel) mari-estel |
| 2024-11-14 11:07:14 +0100 | hgolden | (~hgolden@2603:8000:9d00:3ed1:6c70:1ac0:d127:74dd) (Ping timeout: 260 seconds) |
| 2024-11-14 11:08:17 +0100 | mari-estel | (~mari-este@user/mari-estel) (Ping timeout: 248 seconds) |
| 2024-11-14 11:10:27 +0100 | mari-estel | (~mari-este@user/mari-estel) mari-estel |
| 2024-11-14 11:10:45 +0100 | mari18976 | (~mari-este@user/mari-estel) (Read error: Connection reset by peer) |
| 2024-11-14 11:12:07 +0100 | mari24610 | (~mari-este@user/mari-estel) mari-estel |
| 2024-11-14 11:14:04 +0100 | lxsameer | (~lxsameer@Serene/lxsameer) lxsameer |
| 2024-11-14 11:15:10 +0100 | xff0x | (~xff0x@fsb6a9491c.tkyc517.ap.nuro.jp) (Ping timeout: 252 seconds) |
| 2024-11-14 11:15:12 +0100 | mari-estel | (~mari-este@user/mari-estel) (Ping timeout: 276 seconds) |
| 2024-11-14 11:20:44 +0100 | mari-estel | (~mari-este@user/mari-estel) mari-estel |
| 2024-11-14 11:23:39 +0100 | mari24610 | (~mari-este@user/mari-estel) (Ping timeout: 276 seconds) |
| 2024-11-14 11:24:27 +0100 | ash3en | (~Thunderbi@149.222.147.110) ash3en |
| 2024-11-14 11:27:17 +0100 | Digitteknohippie | (~user@user/digit) Digit |
| 2024-11-14 11:27:49 +0100 | Digit | (~user@user/digit) (Ping timeout: 260 seconds) |
| 2024-11-14 11:28:05 +0100 | ash3en | (~Thunderbi@149.222.147.110) (Client Quit) |
| 2024-11-14 11:32:25 +0100 | Smiles | (uid551636@id-551636.lymington.irccloud.com) (Quit: Connection closed for inactivity) |
| 2024-11-14 11:33:37 +0100 | Digitteknohippie | Digit |
| 2024-11-14 11:49:20 +0100 | mikko | (~mikko@user/mikko) mikko |
| 2024-11-14 11:57:08 +0100 | mari-estel | (~mari-este@user/mari-estel) (Remote host closed the connection) |
| 2024-11-14 11:57:18 +0100 | mari-estel | (~mari-este@user/mari-estel) mari-estel |
| 2024-11-14 11:58:42 +0100 | mari-estel | (~mari-este@user/mari-estel) (Remote host closed the connection) |
| 2024-11-14 11:58:53 +0100 | mari-estel | (~mari-este@user/mari-estel) mari-estel |
| 2024-11-14 12:00:01 +0100 | Smiles | (uid551636@id-551636.lymington.irccloud.com) Smiles |
| 2024-11-14 12:05:29 +0100 | mari96334 | (~mari-este@user/mari-estel) mari-estel |
| 2024-11-14 12:06:53 +0100 | mari96334 | (~mari-este@user/mari-estel) (Remote host closed the connection) |
| 2024-11-14 12:07:05 +0100 | mari89179 | (~mari-este@user/mari-estel) mari-estel |
| 2024-11-14 12:07:42 +0100 | mari-estel | (~mari-este@user/mari-estel) (Ping timeout: 252 seconds) |
| 2024-11-14 12:11:27 +0100 | xff0x | (~xff0x@ai080132.d.east.v6connect.net) |
| 2024-11-14 12:22:06 +0100 | jero98772 | (~jero98772@190.158.28.32) |
| 2024-11-14 12:26:32 +0100 | __monty__ | (~toonn@user/toonn) toonn |
| 2024-11-14 12:38:40 +0100 | mari-estel | (~mari-este@user/mari-estel) mari-estel |
| 2024-11-14 12:40:42 +0100 | mari89179 | (~mari-este@user/mari-estel) (Ping timeout: 252 seconds) |
| 2024-11-14 12:42:19 +0100 | mari29333 | (~mari-este@user/mari-estel) mari-estel |
| 2024-11-14 12:43:13 +0100 | mari-estel | (~mari-este@user/mari-estel) (Read error: Connection reset by peer) |
| 2024-11-14 12:43:53 +0100 | mari-estel | (~mari-este@user/mari-estel) mari-estel |
| 2024-11-14 12:46:03 +0100 | mari-estel | (~mari-este@user/mari-estel) (Client Quit) |
| 2024-11-14 12:47:34 +0100 | mari29333 | (~mari-este@user/mari-estel) (Ping timeout: 260 seconds) |
| 2024-11-14 12:52:05 +0100 | pavonia | (~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 +0100 | jero98772 | (~jero98772@190.158.28.32) (Remote host closed the connection) |
| 2024-11-14 13:00:04 +0100 | caconym | (~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 +0100 | caconym | (~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 +0100 | acidjnk | (~acidjnk@p200300d6e7283f73687bc11ede7922f8.dip0.t-ipconnect.de) (Ping timeout: 248 seconds) |
| 2024-11-14 13:09:11 +0100 | misterfish | (~misterfis@31-161-39-137.biz.kpn.net) (Ping timeout: 252 seconds) |
| 2024-11-14 13:09:23 +0100 | mari-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 +0100 | hellwolf | like 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 +0100 | housemate | (~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 +0100 | mari59415 | (~mari-este@user/mari-estel) mari-estel |
| 2024-11-14 13:24:25 +0100 | arahael_ | (~arahael@user/arahael) (Quit: leaving) |
| 2024-11-14 13:25:23 +0100 | arahael_ | (~arahael@user/arahael) arahael |
| 2024-11-14 13:26:03 +0100 | mari-estel | (~mari-este@user/mari-estel) (Ping timeout: 252 seconds) |
| 2024-11-14 13:26:39 +0100 | tromp | (~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 +0100 | misterfish | (~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 +0100 | haskellbridge | (~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 +0100 | haskellbridge | (~hackager@syn-024-093-192-219.res.spectrum.com) hackager |
| 2024-11-14 13:32:36 +0100 | ChanServ | +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 +0100 | mari-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 +0100 | mari59415 | (~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 +0100 | mari73904 | (~mari-este@user/mari-estel) mari-estel |
| 2024-11-14 13:44:19 +0100 | mari-estel | (~mari-este@user/mari-estel) (Read error: Connection reset by peer) |
| 2024-11-14 13:44:51 +0100 | mari-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 +0100 | mari-estel | (~mari-este@user/mari-estel) (Client Quit) |
| 2024-11-14 13:47:50 +0100 | mari73904 | (~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 +0100 | alphazone | (~alphazone@2.219.56.221) |