| 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) |
| 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? |
| 2024-11-14 14:16:30 +0100 | <bailsman> | If you expect to touch every element, just use map. |
| 2024-11-14 14:16:51 +0100 | <geekosaur> | pretty much |
| 2024-11-14 14:17:21 +0100 | <geekosaur> | it's still going to do copies, I think, and more of them the more elements you touch. but I'mnot sure how that plays out for vector |
| 2024-11-14 14:18:05 +0100 | <geekosaur> | for Array it's split into "cards" and modifications within a single card are batched so only a single copy needs to be done by the mutator, AIUI |
| 2024-11-14 14:18:13 +0100 | <bailsman> | I tried look at it with -ddump-simpl and the mutable version doesn't compile to simple code at all. What should be like 5 assembly instructions turns into several pages of assembly. |
| 2024-11-14 14:18:30 +0100 | <geekosaur> | but that's built into GC and I don't think vector can take advantage of it |
| 2024-11-14 14:18:58 +0100 | <bailsman> | I think if you need a mutable algorithm maybe you should do a CFFI or something. |
| 2024-11-14 14:24:13 +0100 | alexherbo2 | (~alexherbo@2a02-8440-3313-668b-a9ec-921f-0511-ee3f.rev.sfr.net) alexherbo2 |
| 2024-11-14 14:32:56 +0100 | weary-traveler | (~user@user/user363627) (Remote host closed the connection) |
| 2024-11-14 14:33:10 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2024-11-14 14:35:46 +0100 | acidjnk | (~acidjnk@p200300d6e7283f73687bc11ede7922f8.dip0.t-ipconnect.de) acidjnk |
| 2024-11-14 14:38:28 +0100 | mari-estel | (~mari-este@user/mari-estel) mari-estel |
| 2024-11-14 14:48:24 +0100 | misterfish | (~misterfis@31-161-39-137.biz.kpn.net) (Ping timeout: 276 seconds) |
| 2024-11-14 14:50:45 +0100 | weary-traveler | (~user@user/user363627) user363627 |
| 2024-11-14 14:56:06 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Quit: = "") |
| 2024-11-14 15:01:26 +0100 | ash3en | (~Thunderbi@149.222.147.110) ash3en |
| 2024-11-14 15:05:34 +0100 | ash3en | (~Thunderbi@149.222.147.110) (Client Quit) |
| 2024-11-14 15:06:31 +0100 | L29Ah | (~L29Ah@wikipedia/L29Ah) (Ping timeout: 265 seconds) |
| 2024-11-14 15:10:02 +0100 | <dminuoso> | bailsman: Do you have the actual code and the generated core to look at? |
| 2024-11-14 15:16:32 +0100 | mari-estel | (~mari-este@user/mari-estel) (Quit: errands) |
| 2024-11-14 15:18:37 +0100 | Sgeo | (~Sgeo@user/sgeo) Sgeo |
| 2024-11-14 15:30:28 +0100 | mari-estel | (~mari-este@user/mari-estel) mari-estel |
| 2024-11-14 15:35:09 +0100 | ash3en | (~Thunderbi@149.222.147.110) ash3en |
| 2024-11-14 15:35:40 +0100 | alexherbo2 | (~alexherbo@2a02-8440-3313-668b-a9ec-921f-0511-ee3f.rev.sfr.net) (Remote host closed the connection) |
| 2024-11-14 15:35:45 +0100 | ash3en | (~Thunderbi@149.222.147.110) (Client Quit) |
| 2024-11-14 15:35:59 +0100 | alexherbo2 | (~alexherbo@2a02-8440-3313-668b-a9ec-921f-0511-ee3f.rev.sfr.net) alexherbo2 |
| 2024-11-14 15:36:27 +0100 | yaroot | (~yaroot@2400:4052:ac0:d901:1cf4:2aff:fe51:c04c) (Read error: Connection reset by peer) |
| 2024-11-14 15:36:41 +0100 | yaroot | (~yaroot@2400:4052:ac0:d901:1cf4:2aff:fe51:c04c) yaroot |
| 2024-11-14 15:39:55 +0100 | Cadey | (~cadey@perl/impostor/xe) (Quit: WeeChat 4.4.2) |
| 2024-11-14 15:41:12 +0100 | weary-traveler | (~user@user/user363627) (Quit: Konversation terminated!) |
| 2024-11-14 15:47:02 +0100 | billchenchina | (~billchenc@2a0d:2580:ff0c:1:e3c9:c52b:a429:5bfe) billchenchina |
| 2024-11-14 15:48:48 +0100 | <bailsman> | Plain old lists are consistently the fastest. I find that somewhat confusing, since in imperative languages linked lists are often slow. |
| 2024-11-14 15:49:41 +0100 | <geekosaur> | if all you're doing is iterating through them, consider that ghc is optimized for that case: think of a list as a loop encoded as data |
| 2024-11-14 15:49:51 +0100 | <hellwolf> | I mean, if you need to do a log of random indexing, it got to be slow. but for stream processing, it is probably the most efficient |
| 2024-11-14 15:50:23 +0100 | <geekosaur> | allocation, gc, and iteration are all optimized because it's so common |
| 2024-11-14 15:50:37 +0100 | <haskellbridge> | <Bowuigi> Reasoning imperatively in functional languages leads to bad performance in general |
| 2024-11-14 15:50:40 +0100 | misterfish | (~misterfis@31-161-39-137.biz.kpn.net) misterfish |
| 2024-11-14 15:51:04 +0100 | ph88 | (~ph88@2a02:8109:9e26:c800:7ee4:dffc:4616:9e2a) |
| 2024-11-14 15:52:00 +0100 | <bailsman> | I thought I needed to do a lot of random indexing. But, now I'm not sure if I shouldn't instead redesign everything so that it does not require random access. |
| 2024-11-14 15:52:55 +0100 | <haskellbridge> | <Bowuigi> Have you tried any functional random access data structures? |
| 2024-11-14 15:53:14 +0100 | <haskellbridge> | <Bowuigi> Data.Map is the first one that comes to mind |
| 2024-11-14 15:53:38 +0100 | <bailsman> | Data.Vector.Map over a vector is consistently 4x slower than regular map over []. (Data.Map is 10x slower) |
| 2024-11-14 15:54:06 +0100 | hgolden | (~hgolden@2603:8000:9d00:3ed1:6c70:1ac0:d127:74dd) hgolden |
| 2024-11-14 15:54:11 +0100 | <hellwolf> | "data Array i e" is also under rated. |
| 2024-11-14 15:54:16 +0100 | <geekosaur> | right, map's going to be one of those cases that [] will work very well for |