| 2024-03-07 00:01:02 +0100 | alexherbo2 | (~alexherbo@2a02-8440-3240-b056-3594-8200-bad6-a60a.rev.sfr.net) (Remote host closed the connection) |
| 2024-03-07 00:01:22 +0100 | alexherbo2 | (~alexherbo@2a02-8440-3240-b056-3594-8200-bad6-a60a.rev.sfr.net) |
| 2024-03-07 00:03:25 +0100 | acidjnk_new3 | (~acidjnk@p200300d6e737e73474a39a603313c7aa.dip0.t-ipconnect.de) (Ping timeout: 264 seconds) |
| 2024-03-07 00:08:07 +0100 | joeyh | (~joeyh@kitenet.net) (Ping timeout: 246 seconds) |
| 2024-03-07 00:08:21 +0100 | joeyh | (joeyh@kitenet.net) |
| 2024-03-07 00:09:25 +0100 | son0p | (~ff@186.121.59.199) (Ping timeout: 264 seconds) |
| 2024-03-07 00:13:15 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2024-03-07 00:18:03 +0100 | tri | (~tri@ool-18bbef1a.static.optonline.net) |
| 2024-03-07 00:21:20 +0100 | michalz | (~michalz@185.246.207.205) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2024-03-07 00:21:32 +0100 | Sgeo | (~Sgeo@user/sgeo) |
| 2024-03-07 00:22:43 +0100 | tri | (~tri@ool-18bbef1a.static.optonline.net) (Ping timeout: 272 seconds) |
| 2024-03-07 00:24:01 +0100 | a51 | (a51@gateway/vpn/protonvpn/a51) (Quit: WeeChat 4.2.1) |
| 2024-03-07 00:29:09 +0100 | Unicorn_Princess | (~Unicorn_P@user/Unicorn-Princess/x-3540542) (Remote host closed the connection) |
| 2024-03-07 00:46:09 +0100 | zmt00 | (~zmt00@user/zmt00) |
| 2024-03-07 00:49:47 +0100 | redmp | (~redmp@eduroam-169-233-149-113.ucsc.edu) (Ping timeout: 264 seconds) |
| 2024-03-07 00:52:48 +0100 | machinedgod | (~machinedg@d173-183-246-216.abhsia.telus.net) (Ping timeout: 255 seconds) |
| 2024-03-07 00:57:46 +0100 | <shapr> | Is there an explicit list of which GHC version have support? |
| 2024-03-07 00:58:06 +0100 | <shapr> | That is, can I drop support for ghc 8 and stick with ghc 9+ ? |
| 2024-03-07 01:03:37 +0100 | Sgeo_ | (~Sgeo@user/sgeo) |
| 2024-03-07 01:04:01 +0100 | Sgeo | (~Sgeo@user/sgeo) (Read error: Connection reset by peer) |
| 2024-03-07 01:04:05 +0100 | mastarija | (~mastarija@141-136-168-205.dsl.iskon.hr) |
| 2024-03-07 01:04:49 +0100 | rvalue | (~rvalue@user/rvalue) (Ping timeout: 246 seconds) |
| 2024-03-07 01:04:53 +0100 | mastarija | (~mastarija@141-136-168-205.dsl.iskon.hr) (Client Quit) |
| 2024-03-07 01:05:15 +0100 | mastarija | (~mastarija@141-136-168-205.dsl.iskon.hr) |
| 2024-03-07 01:05:56 +0100 | ph88 | (~ph88@2a02:8109:9e26:c800:5ab5:db14:e57d:d013) (Remote host closed the connection) |
| 2024-03-07 01:09:16 +0100 | smalltalkman | (uid545680@id-545680.hampstead.irccloud.com) (Quit: Connection closed for inactivity) |
| 2024-03-07 01:12:22 +0100 | rvalue | (~rvalue@user/rvalue) |
| 2024-03-07 01:12:49 +0100 | iteratee | (~kyle@162.218.222.207) (Read error: Connection reset by peer) |
| 2024-03-07 01:12:59 +0100 | iteratee | (~kyle@162.218.222.207) |
| 2024-03-07 01:13:37 +0100 | res0nat0r0844909 | (~Fletch@falcon.whatbox.ca) (Quit: Ping timeout (120 seconds)) |
| 2024-03-07 01:13:51 +0100 | res0nat0r0844909 | (~Fletch@falcon.whatbox.ca) |
| 2024-03-07 01:17:03 +0100 | alexherbo2 | (~alexherbo@2a02-8440-3240-b056-3594-8200-bad6-a60a.rev.sfr.net) (Remote host closed the connection) |
| 2024-03-07 01:17:48 +0100 | dostoyevsky2 | (~sck@user/dostoyevsky2) (Ping timeout: 260 seconds) |
| 2024-03-07 01:18:50 +0100 | tri | (~tri@ool-18bc2e74.dyn.optonline.net) |
| 2024-03-07 01:23:16 +0100 | <geekosaur> | I don't know where it's documented, but the support window is the current and previous release |
| 2024-03-07 01:23:50 +0100 | <geekosaur> | so 9.6 and 9.8 are currently supported (and a new 9.6 release is being prepared, which will probably be its last because 9.10 is on the way) |
| 2024-03-07 01:24:05 +0100 | <geekosaur> | https://gitlab.haskell.org/ghc/ghc/-/wikis/GHC-status |
| 2024-03-07 01:27:14 +0100 | <geekosaur> | some packages have wider ghc support windows, for example HLS supports back to ghc 9.2 |
| 2024-03-07 01:27:22 +0100 | mastarija | (~mastarija@141-136-168-205.dsl.iskon.hr) (Quit: Client closed) |
| 2024-03-07 01:32:14 +0100 | dostoyevsky2 | (~sck@user/dostoyevsky2) |
| 2024-03-07 01:33:11 +0100 | Feuermagier | (~Feuermagi@user/feuermagier) (Quit: Leaving) |
| 2024-03-07 01:33:17 +0100 | mei | (~mei@user/mei) (Remote host closed the connection) |
| 2024-03-07 01:35:41 +0100 | mei | (~mei@user/mei) |
| 2024-03-07 01:39:11 +0100 | tri | (~tri@ool-18bc2e74.dyn.optonline.net) (Quit: Leaving...) |
| 2024-03-07 01:40:24 +0100 | inedia | (~irc@2602:2da:0:80:5054:ff:fe3c:8d93) (Quit: WeeChat 4.1.2) |
| 2024-03-07 01:43:21 +0100 | <geekosaur> | hm, actually I think it's current and past two, but at this point 9.4 is only going to be updated if a severe bug is found (which seems unlikely this late in its life) |
| 2024-03-07 01:54:10 +0100 | motherfsck | (~motherfsc@user/motherfsck) (Ping timeout: 246 seconds) |
| 2024-03-07 01:57:49 +0100 | versatile_ | (~versatile@176.254.244.83) |
| 2024-03-07 01:59:17 +0100 | redmp | (~redmp@mobile-166-177-251-21.mycingular.net) |
| 2024-03-07 02:00:41 +0100 | versatile | (~versatile@176.254.244.83) (Ping timeout: 256 seconds) |
| 2024-03-07 02:07:22 +0100 | motherfsck | (~motherfsc@user/motherfsck) |
| 2024-03-07 02:16:07 +0100 | thegeekinside | (~thegeekin@189.217.83.221) (Remote host closed the connection) |
| 2024-03-07 02:18:02 +0100 | son0p | (~ff@186.121.98.6) |
| 2024-03-07 02:19:34 +0100 | EvanR_ | (~EvanR@user/evanr) |
| 2024-03-07 02:20:02 +0100 | EvanR | (~EvanR@user/evanr) (Read error: Connection reset by peer) |
| 2024-03-07 02:20:22 +0100 | <haskellbridge> | <sm> yea I thought last 3 major releases was common |
| 2024-03-07 02:20:27 +0100 | <haskellbridge> | <sm> but it really depends on your goals |
| 2024-03-07 02:20:35 +0100 | redmp | (~redmp@mobile-166-177-251-21.mycingular.net) (Ping timeout: 260 seconds) |
| 2024-03-07 02:20:52 +0100 | <haskellbridge> | <sm> and project |
| 2024-03-07 02:23:45 +0100 | ryanbooker | (uid4340@id-4340.hampstead.irccloud.com) |
| 2024-03-07 02:25:57 +0100 | peterbecich | (~Thunderbi@047-229-123-186.res.spectrum.com) |
| 2024-03-07 02:37:54 +0100 | machinedgod | (~machinedg@d173-183-246-216.abhsia.telus.net) |
| 2024-03-07 02:41:39 +0100 | RahulMalhotra | (~RahulMalh@2409:4051:4e1b:efb5::848:eb13) |
| 2024-03-07 02:42:59 +0100 | RahulMalhotra | (~RahulMalh@2409:4051:4e1b:efb5::848:eb13) (Client Quit) |
| 2024-03-07 02:47:13 +0100 | xff0x | (~xff0x@2405:6580:b080:900:4382:9a13:8c84:8575) (Ping timeout: 264 seconds) |
| 2024-03-07 02:48:20 +0100 | Buggys | (Buggys@Buggy.shelltalk.net) (Ping timeout: 256 seconds) |
| 2024-03-07 02:53:40 +0100 | szkl | (uid110435@id-110435.uxbridge.irccloud.com) (Quit: Connection closed for inactivity) |
| 2024-03-07 02:53:52 +0100 | smalltalkman | (uid545680@id-545680.hampstead.irccloud.com) |
| 2024-03-07 02:56:45 +0100 | Buggys | (Buggys@shelltalk.net) |
| 2024-03-07 03:00:30 +0100 | Lord_of_Life_ | (~Lord@user/lord-of-life/x-2819915) |
| 2024-03-07 03:01:11 +0100 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) (Ping timeout: 264 seconds) |
| 2024-03-07 03:01:55 +0100 | Lord_of_Life_ | Lord_of_Life |
| 2024-03-07 03:08:14 +0100 | inedia | (~irc@2600:3c00:e000:287::1) |
| 2024-03-07 03:22:39 +0100 | peterbecich | (~Thunderbi@047-229-123-186.res.spectrum.com) (Ping timeout: 255 seconds) |
| 2024-03-07 03:26:58 +0100 | euleritian | (~euleritia@77.22.252.56) (Ping timeout: 264 seconds) |
| 2024-03-07 03:31:42 +0100 | euleritian | (~euleritia@dynamic-176-006-179-235.176.6.pool.telefonica.de) |
| 2024-03-07 03:33:11 +0100 | igemnace | (~ian@user/igemnace) |
| 2024-03-07 03:34:17 +0100 | Feuermagier | (~Feuermagi@user/feuermagier) |
| 2024-03-07 03:34:41 +0100 | xff0x | (~xff0x@125x103x176x34.ap125.ftth.ucom.ne.jp) |
| 2024-03-07 03:35:55 +0100 | vnogueira | (~vnogueira@user/vnogueira) |
| 2024-03-07 03:42:41 +0100 | mulk | (~mulk@p5b1123d6.dip0.t-ipconnect.de) (Ping timeout: 256 seconds) |
| 2024-03-07 03:43:44 +0100 | mulk | (~mulk@p5b112b94.dip0.t-ipconnect.de) |
| 2024-03-07 03:47:13 +0100 | otto_s | (~user@p4ff2730f.dip0.t-ipconnect.de) (Ping timeout: 256 seconds) |
| 2024-03-07 03:49:04 +0100 | otto_s | (~user@p4ff27fa9.dip0.t-ipconnect.de) |
| 2024-03-07 03:52:27 +0100 | Square2 | (~Square4@user/square) |
| 2024-03-07 03:55:30 +0100 | Square | (~Square@user/square) (Ping timeout: 255 seconds) |
| 2024-03-07 03:57:34 +0100 | machinedgod | (~machinedg@d173-183-246-216.abhsia.telus.net) (Ping timeout: 264 seconds) |
| 2024-03-07 04:00:46 +0100 | Feuermagier | (~Feuermagi@user/feuermagier) (Remote host closed the connection) |
| 2024-03-07 04:05:30 +0100 | tri | (~tri@ool-18bc2e74.dyn.optonline.net) |
| 2024-03-07 04:08:23 +0100 | tri | (~tri@ool-18bc2e74.dyn.optonline.net) (Remote host closed the connection) |
| 2024-03-07 04:08:58 +0100 | tri | (~tri@ool-18bc2e74.dyn.optonline.net) |
| 2024-03-07 04:11:37 +0100 | jargon | (~jargon@154.sub-174-205-226.myvzw.com) (Remote host closed the connection) |
| 2024-03-07 04:15:25 +0100 | tri | (~tri@ool-18bc2e74.dyn.optonline.net) (Ping timeout: 264 seconds) |
| 2024-03-07 04:27:51 +0100 | igemnace | (~ian@user/igemnace) (Read error: Connection reset by peer) |
| 2024-03-07 04:29:47 +0100 | tri | (~tri@ool-18bc2e74.dyn.optonline.net) |
| 2024-03-07 04:30:08 +0100 | Square3 | (~Square4@user/square) |
| 2024-03-07 04:30:19 +0100 | Square2 | (~Square4@user/square) (Ping timeout: 260 seconds) |
| 2024-03-07 04:45:07 +0100 | igemnace | (~ian@user/igemnace) |
| 2024-03-07 04:48:13 +0100 | bilegeek | (~bilegeek@2600:1008:b0a1:15d8:bc27:900c:1b6c:2bce) |
| 2024-03-07 04:48:19 +0100 | <jackdk> | Can anyone recommend me an FRP library for textmode UIs? I'm most familiar with Reflex's Event/Behavior/Dynamic model but I'd be down to try others (I see `bricki-reflex` was last touched seven years ago) |
| 2024-03-07 04:54:46 +0100 | <haskellbridge> | <sm> that'd be the one I expect |
| 2024-03-07 04:56:03 +0100 | <haskellbridge> | <sm> oh, maybe I'm thinking of https://hackage.haskell.org/package/reflex-vty |
| 2024-03-07 04:57:35 +0100 | tri | (~tri@ool-18bc2e74.dyn.optonline.net) (Remote host closed the connection) |
| 2024-03-07 05:00:02 +0100 | tri | (~tri@ool-18bc2e74.dyn.optonline.net) |
| 2024-03-07 05:01:28 +0100 | <geekosaur> | that's what I'd expect it to be anyway; brick is a traditional GUI over vty, I'd expect FRP to also be built atop vty |
| 2024-03-07 05:01:39 +0100 | <geekosaur> | s/GUI/TUI/ |
| 2024-03-07 05:02:06 +0100 | <jackdk> | somehow I missed that reflex-vty existed. Thanks both |
| 2024-03-07 05:02:16 +0100 | td_ | (~td@i53870914.versanet.de) (Ping timeout: 260 seconds) |
| 2024-03-07 05:03:52 +0100 | td_ | (~td@i53870916.versanet.de) |
| 2024-03-07 05:25:08 +0100 | bontaq`` | (~user@ool-45779c03.dyn.optonline.net) (Ping timeout: 260 seconds) |
| 2024-03-07 05:26:36 +0100 | aforemny_ | (~aforemny@i59F516F6.versanet.de) |
| 2024-03-07 05:28:01 +0100 | aforemny | (~aforemny@i59F516E5.versanet.de) (Ping timeout: 264 seconds) |
| 2024-03-07 05:29:20 +0100 | fansly | (~fansly@2001:448a:2010:476e:9117:3da:8e3c:52b0) |
| 2024-03-07 05:30:00 +0100 | JamesMowery | (~JamesMowe@ip98-171-80-211.ph.ph.cox.net) |
| 2024-03-07 05:42:29 +0100 | waleee | (~waleee@h-176-10-144-38.NA.cust.bahnhof.se) (Ping timeout: 240 seconds) |
| 2024-03-07 05:43:58 +0100 | euleritian | (~euleritia@dynamic-176-006-179-235.176.6.pool.telefonica.de) (Read error: Connection reset by peer) |
| 2024-03-07 05:44:16 +0100 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) |
| 2024-03-07 05:48:29 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) |
| 2024-03-07 05:55:18 +0100 | redmp | (~redmp@mobile-166-171-248-7.mycingular.net) |
| 2024-03-07 06:03:24 +0100 | _ht | (~Thunderbi@28-52-174-82.ftth.glasoperator.nl) |
| 2024-03-07 06:05:57 +0100 | fansly | (~fansly@2001:448a:2010:476e:9117:3da:8e3c:52b0) (Quit: Quit) |
| 2024-03-07 06:07:28 +0100 | fansly | (~fansly@2001:448a:2010:476e:9117:3da:8e3c:52b0) |
| 2024-03-07 06:07:41 +0100 | fansly | (~fansly@2001:448a:2010:476e:9117:3da:8e3c:52b0) (Remote host closed the connection) |
| 2024-03-07 06:07:43 +0100 | peterbecich | (~Thunderbi@047-229-123-186.res.spectrum.com) |
| 2024-03-07 06:07:58 +0100 | michalz | (~michalz@185.246.207.205) |
| 2024-03-07 06:08:47 +0100 | ryanbooker | (uid4340@id-4340.hampstead.irccloud.com) (Quit: Connection closed for inactivity) |
| 2024-03-07 06:11:52 +0100 | tri | (~tri@ool-18bc2e74.dyn.optonline.net) (Remote host closed the connection) |
| 2024-03-07 06:14:57 +0100 | tri | (~tri@ool-18bc2e74.dyn.optonline.net) |
| 2024-03-07 06:27:52 +0100 | michalz | (~michalz@185.246.207.205) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2024-03-07 06:30:38 +0100 | michalz | (~michalz@185.246.207.200) |
| 2024-03-07 06:30:48 +0100 | edwardk | wakes up and checks in on how things are going around here. |
| 2024-03-07 06:35:56 +0100 | jargon | (~jargon@154.sub-174-205-226.myvzw.com) |
| 2024-03-07 06:36:57 +0100 | fansly | (~fansly@2001:448a:2010:476e:9117:3da:8e3c:52b0) |
| 2024-03-07 06:39:45 +0100 | qqq | (~qqq@92.43.167.61) (Remote host closed the connection) |
| 2024-03-07 06:41:18 +0100 | fansly | (~fansly@2001:448a:2010:476e:9117:3da:8e3c:52b0) (Client Quit) |
| 2024-03-07 06:43:53 +0100 | jargon | (~jargon@154.sub-174-205-226.myvzw.com) (Remote host closed the connection) |
| 2024-03-07 06:47:23 +0100 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Ping timeout: 264 seconds) |
| 2024-03-07 06:47:57 +0100 | euleritian | (~euleritia@dynamic-176-006-179-235.176.6.pool.telefonica.de) |
| 2024-03-07 06:48:17 +0100 | euleritian | (~euleritia@dynamic-176-006-179-235.176.6.pool.telefonica.de) (Read error: Connection reset by peer) |
| 2024-03-07 06:49:40 +0100 | euleritian | (~euleritia@dynamic-176-006-179-235.176.6.pool.telefonica.de) |
| 2024-03-07 06:55:49 +0100 | mei | (~mei@user/mei) (Remote host closed the connection) |
| 2024-03-07 06:58:13 +0100 | mei | (~mei@user/mei) |
| 2024-03-07 07:02:55 +0100 | mjrosenb | (~mjrosenb@pool-96-232-177-77.nycmny.fios.verizon.net) (Ping timeout: 260 seconds) |
| 2024-03-07 07:09:44 +0100 | euleritian | (~euleritia@dynamic-176-006-179-235.176.6.pool.telefonica.de) (Read error: Connection reset by peer) |
| 2024-03-07 07:10:18 +0100 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) |
| 2024-03-07 07:10:23 +0100 | peterbecich | (~Thunderbi@047-229-123-186.res.spectrum.com) (Ping timeout: 260 seconds) |
| 2024-03-07 07:12:16 +0100 | tri | (~tri@ool-18bc2e74.dyn.optonline.net) (Remote host closed the connection) |
| 2024-03-07 07:16:53 +0100 | redmp | (~redmp@mobile-166-171-248-7.mycingular.net) (Ping timeout: 256 seconds) |
| 2024-03-07 07:18:25 +0100 | takuan | (~takuan@178-116-218-225.access.telenet.be) |
| 2024-03-07 07:23:10 +0100 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Ping timeout: 246 seconds) |
| 2024-03-07 07:23:36 +0100 | euleritian | (~euleritia@dynamic-176-006-179-235.176.6.pool.telefonica.de) |
| 2024-03-07 07:23:40 +0100 | danza | (~francesco@151.43.168.41) |
| 2024-03-07 07:24:02 +0100 | Lycurgus | (~georg@user/Lycurgus) |
| 2024-03-07 07:24:33 +0100 | mjrosenb | (~mjrosenb@pool-96-232-177-77.nycmny.fios.verizon.net) |
| 2024-03-07 07:25:35 +0100 | ec | (~ec@gateway/tor-sasl/ec) (Remote host closed the connection) |
| 2024-03-07 07:26:14 +0100 | ec | (~ec@gateway/tor-sasl/ec) |
| 2024-03-07 07:29:36 +0100 | raehik | (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) |
| 2024-03-07 07:34:15 +0100 | tri | (~tri@ool-18bc2e74.dyn.optonline.net) |
| 2024-03-07 07:36:59 +0100 | <haskellbridge> | <sm> good morning edwardk ☀️ |
| 2024-03-07 07:37:13 +0100 | _ht | (~Thunderbi@28-52-174-82.ftth.glasoperator.nl) (Remote host closed the connection) |
| 2024-03-07 07:54:27 +0100 | tri | (~tri@ool-18bc2e74.dyn.optonline.net) (Remote host closed the connection) |
| 2024-03-07 07:55:58 +0100 | sord937 | (~sord937@gateway/tor-sasl/sord937) |
| 2024-03-07 07:56:13 +0100 | petrichor | (~znc-user@user/petrichor) (Ping timeout: 264 seconds) |
| 2024-03-07 07:57:15 +0100 | tri | (~tri@ool-18bc2e74.dyn.optonline.net) |
| 2024-03-07 07:57:57 +0100 | echoreply | (~echoreply@45.32.163.16) (Quit: WeeChat 2.8) |
| 2024-03-07 07:58:35 +0100 | acidjnk_new3 | (~acidjnk@p200300d6e737e753f8b7044289a8517e.dip0.t-ipconnect.de) |
| 2024-03-07 07:59:17 +0100 | echoreply | (~echoreply@45.32.163.16) |
| 2024-03-07 08:06:12 +0100 | gabiruh | (~gabiruh@vps19177.publiccloud.com.br) (Quit: ZNC 1.7.5 - https://znc.in) |
| 2024-03-07 08:19:04 +0100 | tri | (~tri@ool-18bc2e74.dyn.optonline.net) (Remote host closed the connection) |
| 2024-03-07 08:20:49 +0100 | ski | (~ski@ext-1-033.eduroam.chalmers.se) (Ping timeout: 264 seconds) |
| 2024-03-07 08:23:48 +0100 | fmd | (~fmd@user/framend) |
| 2024-03-07 08:25:44 +0100 | danza | (~francesco@151.43.168.41) (Ping timeout: 260 seconds) |
| 2024-03-07 08:26:42 +0100 | gabiruh | (~gabiruh@vps19177.publiccloud.com.br) |
| 2024-03-07 08:27:06 +0100 | zetef | (~quassel@95.77.17.251) |
| 2024-03-07 08:27:50 +0100 | mei | (~mei@user/mei) (Remote host closed the connection) |
| 2024-03-07 08:30:15 +0100 | mei | (~mei@user/mei) |
| 2024-03-07 08:33:14 +0100 | tr_ev | (~trev@user/trev) |
| 2024-03-07 08:36:56 +0100 | raehik | (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) (Ping timeout: 260 seconds) |
| 2024-03-07 08:38:39 +0100 | phma | (~phma@2001:5b0:212a:dbd8:9225:61ca:7b7d:b499) (Read error: Connection reset by peer) |
| 2024-03-07 08:39:23 +0100 | phma | (phma@2001:5b0:211f:bff8:ed6a:61e2:ef0c:3875) |
| 2024-03-07 08:42:44 +0100 | julie_pilgrim | (~julie_pil@user/julie-pilgrim/x-1240752) |
| 2024-03-07 08:42:47 +0100 | lortabac | (~lortabac@2a01:e0a:541:b8f0:55ab:e185:7f81:54a4) |
| 2024-03-07 08:45:34 +0100 | raehik | (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) |
| 2024-03-07 08:46:59 +0100 | CiaoSen | (~Jura@2a05:5800:2ad:4600:e6b9:7aff:fe80:3d03) |
| 2024-03-07 08:50:18 +0100 | Sgeo_ | (~Sgeo@user/sgeo) (Read error: Connection reset by peer) |
| 2024-03-07 08:53:46 +0100 | euleritian | (~euleritia@dynamic-176-006-179-235.176.6.pool.telefonica.de) (Read error: Connection reset by peer) |
| 2024-03-07 08:54:04 +0100 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) |
| 2024-03-07 08:57:14 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2024-03-07 09:00:03 +0100 | oo_miguel | (~Thunderbi@78-11-181-16.static.ip.netia.com.pl) |
| 2024-03-07 09:06:27 +0100 | zetef | (~quassel@95.77.17.251) (Ping timeout: 255 seconds) |
| 2024-03-07 09:06:40 +0100 | misterfish | (~misterfis@46.44.172.198) |
| 2024-03-07 09:12:46 +0100 | azimut | (~azimut@gateway/tor-sasl/azimut) (Ping timeout: 260 seconds) |
| 2024-03-07 09:12:52 +0100 | chele | (~chele@user/chele) |
| 2024-03-07 09:15:50 +0100 | zetef | (~quassel@95.77.17.251) |
| 2024-03-07 09:22:38 +0100 | danse-nr3 | (~danse@185.211.81.183) |
| 2024-03-07 09:25:29 +0100 | dcoutts | (~duncan@cpc69402-oxfd27-2-0-cust903.4-3.cable.virginm.net) (Ping timeout: 272 seconds) |
| 2024-03-07 09:34:41 +0100 | tzh | (~tzh@c-73-164-206-160.hsd1.or.comcast.net) (Quit: zzz) |
| 2024-03-07 09:40:46 +0100 | vnogueira | (~vnogueira@user/vnogueira) (Ping timeout: 260 seconds) |
| 2024-03-07 09:41:16 +0100 | mei | (~mei@user/mei) (Remote host closed the connection) |
| 2024-03-07 09:41:58 +0100 | vnogueira | (~vnogueira@user/vnogueira) |
| 2024-03-07 09:41:58 +0100 | machinedgod | (~machinedg@d173-183-246-216.abhsia.telus.net) |
| 2024-03-07 09:43:42 +0100 | mei | (~mei@user/mei) |
| 2024-03-07 09:50:59 +0100 | <absence> | Is it possible to convert from "forall m. C m => a -> m b" to "a -> forall m. C m => m b"? It's kind of like flip, but... :P |
| 2024-03-07 09:54:24 +0100 | trev | (~trev@user/trev) (Remote host closed the connection) |
| 2024-03-07 09:54:40 +0100 | trev | (~trev@user/trev) |
| 2024-03-07 09:55:29 +0100 | <tomsmeding> | absence: https://play.haskell.org/saved/BILj1Fqs seems like ghc just... does it? |
| 2024-03-07 09:55:43 +0100 | <tomsmeding> | I guess the answer is "eta-expand" |
| 2024-03-07 09:56:55 +0100 | tr_ev | (~trev@user/trev) (Quit: tr_ev) |
| 2024-03-07 09:57:35 +0100 | notzmv | (~daniel@user/notzmv) (Remote host closed the connection) |
| 2024-03-07 09:58:21 +0100 | <danse-nr3> | does not look like flip though, i think the semantic is different (also probably needs parenthesis on the right) |
| 2024-03-07 09:59:44 +0100 | <probie> | you don't even need to eta-expand in older versions of GHC |
| 2024-03-07 10:00:27 +0100 | notzmv | (~daniel@user/notzmv) |
| 2024-03-07 10:02:18 +0100 | <danse-nr3> | oh had to check tomsmeding's snippet |
| 2024-03-07 10:02:30 +0100 | Unicorn_Princess | (~Unicorn_P@user/Unicorn-Princess/x-3540542) |
| 2024-03-07 10:02:42 +0100 | <ncf> | it is a kind of dependent flip |
| 2024-03-07 10:02:51 +0100 | <tomsmeding> | in Core it's a flip |
| 2024-03-07 10:02:52 +0100 | <absence> | tomsmeding: How about when you fmap such a function? |
| 2024-03-07 10:03:08 +0100 | <tomsmeding> | absence: add abundant type signatures, then see how many you can remove |
| 2024-03-07 10:03:38 +0100 | <tomsmeding> | when working with explicitly polymorphic functions, you need lots of type signatures |
| 2024-03-07 10:04:46 +0100 | julie_pilgrim | (~julie_pil@user/julie-pilgrim/x-1240752) (Remote host closed the connection) |
| 2024-03-07 10:05:17 +0100 | julie_pilgrim | (~julie_pil@user/julie-pilgrim/x-1240752) |
| 2024-03-07 10:05:35 +0100 | bilegeek_ | (~bilegeek@2600:1008:b0a1:15d8:bc27:900c:1b6c:2bce) |
| 2024-03-07 10:05:41 +0100 | econo_ | (uid147250@id-147250.tinside.irccloud.com) (Quit: Connection closed for inactivity) |
| 2024-03-07 10:07:58 +0100 | jau | (~user@2a04:4540:7212:6d00:e5f3:df01:adee:2cc8) |
| 2024-03-07 10:08:09 +0100 | <absence> | tomsmeding: https://play.haskell.org/saved/YxvpfR3U |
| 2024-03-07 10:08:16 +0100 | bilegeek | (~bilegeek@2600:1008:b0a1:15d8:bc27:900c:1b6c:2bce) (Ping timeout: 268 seconds) |
| 2024-03-07 10:09:50 +0100 | <probie> | absence: https://play.haskell.org/saved/LZ1rvzya |
| 2024-03-07 10:09:54 +0100 | <tomsmeding> | absence: https://play.haskell.org/saved/Ve1BBcxh |
| 2024-03-07 10:09:56 +0100 | <tomsmeding> | oh |
| 2024-03-07 10:10:01 +0100 | <tomsmeding> | lol |
| 2024-03-07 10:10:06 +0100 | <tomsmeding> | take probie's version |
| 2024-03-07 10:10:24 +0100 | ania123 | (~ania123@94-43-231-47.dsl.utg.ge) |
| 2024-03-07 10:10:25 +0100 | travgm__ | (~travgm@2600:100e:a121:ef84:212e:f7c5:fded:46ea) |
| 2024-03-07 10:11:54 +0100 | <absence> | Ahh of course, lambdas can be eta expanded as well. Thanks! |
| 2024-03-07 10:12:36 +0100 | bilegeek_ | (~bilegeek@2600:1008:b0a1:15d8:bc27:900c:1b6c:2bce) (Ping timeout: 256 seconds) |
| 2024-03-07 10:13:07 +0100 | travgm_ | (~travgm@2600:100e:a121:ef84:212e:f7c5:fded:46ea) (Ping timeout: 256 seconds) |
| 2024-03-07 10:14:15 +0100 | misterfish | (~misterfis@46.44.172.198) (Ping timeout: 256 seconds) |
| 2024-03-07 10:15:43 +0100 | fmd | (~fmd@user/framend) (Quit: So much programs to build…) |
| 2024-03-07 10:25:07 +0100 | ubert | (~Thunderbi@2a02:8109:ab8a:5a00:e52f:c589:18bb:7d17) |
| 2024-03-07 10:30:02 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2024-03-07 10:31:57 +0100 | ft | (~ft@p508db2e6.dip0.t-ipconnect.de) (Quit: leaving) |
| 2024-03-07 10:35:32 +0100 | notzmv | (~daniel@user/notzmv) (Read error: Connection reset by peer) |
| 2024-03-07 10:36:53 +0100 | misterfish | (~misterfis@84.53.85.146) |
| 2024-03-07 10:39:36 +0100 | notzmv | (~daniel@user/notzmv) |
| 2024-03-07 10:41:33 +0100 | kuribas | (~user@ip-188-118-57-242.reverse.destiny.be) |
| 2024-03-07 10:41:41 +0100 | danse-nr3 | (~danse@185.211.81.183) (Ping timeout: 252 seconds) |
| 2024-03-07 10:42:15 +0100 | zetef | (~quassel@95.77.17.251) (Quit: No Ping reply in 180 seconds.) |
| 2024-03-07 10:47:52 +0100 | danse-nr3 | (~danse@151.43.166.155) |
| 2024-03-07 10:50:58 +0100 | dcoutts | (~duncan@cpc69402-oxfd27-2-0-cust903.4-3.cable.virginm.net) |
| 2024-03-07 10:52:21 +0100 | szkl | (uid110435@id-110435.uxbridge.irccloud.com) |
| 2024-03-07 10:52:30 +0100 | danse-nr3 | (~danse@151.43.166.155) (Read error: Connection reset by peer) |
| 2024-03-07 10:53:37 +0100 | adanwan | (~adanwan@gateway/tor-sasl/adanwan) (Quit: _) |
| 2024-03-07 10:53:47 +0100 | danse-nr3 | (~danse@151.43.211.246) |
| 2024-03-07 10:53:51 +0100 | adanwan | (~adanwan@gateway/tor-sasl/adanwan) |
| 2024-03-07 10:56:27 +0100 | monochrom | (trebla@216.138.220.146) (Quit: ZNC 1.8.2+deb3.1 - https://znc.in) |
| 2024-03-07 11:05:48 +0100 | zetef | (~quassel@93.122.251.174) |
| 2024-03-07 11:06:11 +0100 | xff0x | (~xff0x@125x103x176x34.ap125.ftth.ucom.ne.jp) (Ping timeout: 272 seconds) |
| 2024-03-07 11:08:54 +0100 | monochrom | (trebla@216.138.220.146) |
| 2024-03-07 11:15:22 +0100 | julie_pilgrim | (~julie_pil@user/julie-pilgrim/x-1240752) (Remote host closed the connection) |
| 2024-03-07 11:15:42 +0100 | julie_pilgrim | (~julie_pil@user/julie-pilgrim/x-1240752) |
| 2024-03-07 11:16:03 +0100 | cfricke | (~cfricke@user/cfricke) |
| 2024-03-07 11:26:16 +0100 | lortabac | (~lortabac@2a01:e0a:541:b8f0:55ab:e185:7f81:54a4) (Ping timeout: 256 seconds) |
| 2024-03-07 11:28:53 +0100 | julie_pilgrim | (~julie_pil@user/julie-pilgrim/x-1240752) (Remote host closed the connection) |
| 2024-03-07 11:32:35 +0100 | zetef | (~quassel@93.122.251.174) (Read error: Connection reset by peer) |
| 2024-03-07 11:32:52 +0100 | destituion | (~destituio@2a02:2121:34a:61a6:afbf:6cfe:62a6:9770) (Ping timeout: 260 seconds) |
| 2024-03-07 11:36:54 +0100 | zetef | (~quassel@95.77.17.251) |
| 2024-03-07 11:40:47 +0100 | lortabac | (~lortabac@2a01:e0a:541:b8f0:55ab:e185:7f81:54a4) |
| 2024-03-07 11:45:30 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2024-03-07 11:50:55 +0100 | Square3 | (~Square4@user/square) (Ping timeout: 246 seconds) |
| 2024-03-07 11:56:19 +0100 | [[PSYCHIATRIST | (~PSYCHIAT@46.197.13.174) |
| 2024-03-07 12:02:09 +0100 | ski | (~ski@ext-1-033.eduroam.chalmers.se) |
| 2024-03-07 12:07:37 +0100 | xff0x | (~xff0x@2405:6580:b080:900:e821:772c:646b:bc1f) |
| 2024-03-07 12:08:38 +0100 | causal | (~eric@50.35.85.7) |
| 2024-03-07 12:15:11 +0100 | __monty__ | (~toonn@user/toonn) |
| 2024-03-07 12:17:59 +0100 | [[PSYCHIATRIST | (~PSYCHIAT@46.197.13.174) (Quit: Connection closed) |
| 2024-03-07 12:18:48 +0100 | sidd-dino | (~sidd-dino@gateway/tor-sasl/sidd-dino) |
| 2024-03-07 12:22:13 +0100 | lortabac | (~lortabac@2a01:e0a:541:b8f0:55ab:e185:7f81:54a4) (Ping timeout: 255 seconds) |
| 2024-03-07 12:25:20 +0100 | igemnace | (~ian@user/igemnace) (Read error: Connection reset by peer) |
| 2024-03-07 12:27:25 +0100 | Unicorn_Princess | (~Unicorn_P@user/Unicorn-Princess/x-3540542) (Remote host closed the connection) |
| 2024-03-07 12:28:14 +0100 | a51 | (a51@gateway/vpn/protonvpn/a51) |
| 2024-03-07 12:35:01 +0100 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Ping timeout: 246 seconds) |
| 2024-03-07 12:35:31 +0100 | euleritian | (~euleritia@dynamic-176-006-203-227.176.6.pool.telefonica.de) |
| 2024-03-07 12:36:44 +0100 | ania123 | (~ania123@94-43-231-47.dsl.utg.ge) (Quit: Client closed) |
| 2024-03-07 12:40:42 +0100 | euleritian | (~euleritia@dynamic-176-006-203-227.176.6.pool.telefonica.de) (Read error: Connection reset by peer) |
| 2024-03-07 12:41:06 +0100 | euleritian | (~euleritia@77.22.252.56) |
| 2024-03-07 12:43:11 +0100 | danse-nr3 | (~danse@151.43.211.246) (Ping timeout: 264 seconds) |
| 2024-03-07 12:43:17 +0100 | igemnace | (~ian@user/igemnace) |
| 2024-03-07 12:45:31 +0100 | euleritian | (~euleritia@77.22.252.56) (Read error: Connection reset by peer) |
| 2024-03-07 12:45:37 +0100 | ski | (~ski@ext-1-033.eduroam.chalmers.se) (Ping timeout: 255 seconds) |
| 2024-03-07 12:46:05 +0100 | euleritian | (~euleritia@77.22.252.56) |
| 2024-03-07 12:47:06 +0100 | ski | (~ski@ext-1-033.eduroam.chalmers.se) |
| 2024-03-07 12:55:14 +0100 | zetef | (~quassel@95.77.17.251) (Remote host closed the connection) |
| 2024-03-07 12:57:41 +0100 | lortabac | (~lortabac@2a01:e0a:541:b8f0:55ab:e185:7f81:54a4) |
| 2024-03-07 13:05:22 +0100 | danse-nr3 | (~danse@151.43.155.172) |
| 2024-03-07 13:25:48 +0100 | gehmehgeh | (~user@user/gehmehgeh) |
| 2024-03-07 13:26:07 +0100 | CiaoSen | (~Jura@2a05:5800:2ad:4600:e6b9:7aff:fe80:3d03) (Ping timeout: 246 seconds) |
| 2024-03-07 13:26:19 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Quit: = "") |
| 2024-03-07 13:32:05 +0100 | gehmehgeh | gmg |
| 2024-03-07 13:45:46 +0100 | euleritian | (~euleritia@77.22.252.56) (Read error: Connection reset by peer) |
| 2024-03-07 13:46:36 +0100 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) |
| 2024-03-07 13:58:22 +0100 | gabiruh | (~gabiruh@vps19177.publiccloud.com.br) (Quit: ZNC 1.7.5 - https://znc.in) |
| 2024-03-07 14:00:15 +0100 | kuribas | (~user@ip-188-118-57-242.reverse.destiny.be) (Remote host closed the connection) |
| 2024-03-07 14:00:25 +0100 | kuribas | (~user@ip-188-118-57-242.reverse.destiny.be) |
| 2024-03-07 14:00:39 +0100 | gmg | (~user@user/gehmehgeh) (Remote host closed the connection) |
| 2024-03-07 14:00:52 +0100 | gabiruh | (~gabiruh@vps19177.publiccloud.com.br) |
| 2024-03-07 14:01:27 +0100 | gmg | (~user@user/gehmehgeh) |
| 2024-03-07 14:03:43 +0100 | srz | (~srz@181.228.49.93) |
| 2024-03-07 14:04:28 +0100 | gabiruh | (~gabiruh@vps19177.publiccloud.com.br) (Client Quit) |
| 2024-03-07 14:08:34 +0100 | gabiruh | (~gabiruh@vps19177.publiccloud.com.br) |
| 2024-03-07 14:11:44 +0100 | tr_ev | (~trev@user/trev) |
| 2024-03-07 14:14:49 +0100 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Ping timeout: 264 seconds) |
| 2024-03-07 14:17:49 +0100 | euleritian | (~euleritia@dynamic-176-006-203-227.176.6.pool.telefonica.de) |
| 2024-03-07 14:19:58 +0100 | tr_ev | (~trev@user/trev) (Quit: tr_ev) |
| 2024-03-07 14:19:59 +0100 | euleritian | (~euleritia@dynamic-176-006-203-227.176.6.pool.telefonica.de) (Read error: Connection reset by peer) |
| 2024-03-07 14:21:43 +0100 | euleritian | (~euleritia@77.22.252.56) |
| 2024-03-07 14:21:48 +0100 | L29Ah | (~L29Ah@wikipedia/L29Ah) (Read error: Connection reset by peer) |
| 2024-03-07 14:25:34 +0100 | CiaoSen | (~Jura@2a05:5800:2ad:4600:e6b9:7aff:fe80:3d03) |
| 2024-03-07 14:26:25 +0100 | euleritian | (~euleritia@77.22.252.56) (Ping timeout: 256 seconds) |
| 2024-03-07 14:32:12 +0100 | euleritian | (~euleritia@dynamic-176-006-203-227.176.6.pool.telefonica.de) |
| 2024-03-07 14:32:35 +0100 | euleritian | (~euleritia@dynamic-176-006-203-227.176.6.pool.telefonica.de) (Read error: Connection reset by peer) |
| 2024-03-07 14:33:04 +0100 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) |
| 2024-03-07 14:40:17 +0100 | notzmv | (~daniel@user/notzmv) (Read error: Connection reset by peer) |
| 2024-03-07 14:40:42 +0100 | sord937 | (~sord937@gateway/tor-sasl/sord937) (Remote host closed the connection) |
| 2024-03-07 14:41:05 +0100 | sord937 | (~sord937@gateway/tor-sasl/sord937) |
| 2024-03-07 14:43:41 +0100 | notzmv | (~daniel@user/notzmv) |
| 2024-03-07 14:46:27 +0100 | bontaq`` | (~user@ool-45779c03.dyn.optonline.net) |
| 2024-03-07 14:47:13 +0100 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Ping timeout: 264 seconds) |
| 2024-03-07 14:47:47 +0100 | bwe | (~bwe@2a01:4f8:1c1c:4878::2) |
| 2024-03-07 14:48:21 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2024-03-07 14:50:05 +0100 | misterfish | (~misterfis@84.53.85.146) (Ping timeout: 268 seconds) |
| 2024-03-07 14:50:10 +0100 | euleritian | (~euleritia@dynamic-176-006-203-227.176.6.pool.telefonica.de) |
| 2024-03-07 14:54:41 +0100 | danse-nr3 | (~danse@151.43.155.172) (Ping timeout: 252 seconds) |
| 2024-03-07 14:55:28 +0100 | danse-nr3 | (~danse@151.43.155.172) |
| 2024-03-07 14:55:48 +0100 | <bwe> | Hi, how do I collect errors with Applicative and Monad instances using Semigroup? How do I use the Applicative instance correctly? How do I need to define the Monad instance to NOT short-circuit? https://gist.github.com/benjaminweb/fef460aad1e799f415e25389f9c13783 |
| 2024-03-07 14:57:44 +0100 | zetef | (~quassel@95.77.17.251) |
| 2024-03-07 15:04:45 +0100 | alexherbo2 | (~alexherbo@2a02-8440-3241-19d1-2046-7c34-1287-cba1.rev.sfr.net) |
| 2024-03-07 15:09:39 +0100 | <danse-nr3> | hmm why does it have to be applicative? Maybe you want a reader monad where errors get collected |
| 2024-03-07 15:10:16 +0100 | <[Leary]> | bwe: In the error case for `Monad (Either e)` you have an `e` and an `a -> Either e b`; there's no choice but to stop. You can either restrict yourself to Applicative (see 'validation') or use a Monad that may still produce output even when there are errors (see 'monad-chronicle'). |
| 2024-03-07 15:13:42 +0100 | <danse-nr3> | huh i meant to write "writer monad" ... and i guess i did not get the context of your question. The chronicle monad looks fun though |
| 2024-03-07 15:14:45 +0100 | <[Leary]> | Re `sumAll`/`caller`, I think you want `caller = (\a b c -> a + b + c) <$> f1 <*> f2 <*> f3`. |
| 2024-03-07 15:26:06 +0100 | euleritian | (~euleritia@dynamic-176-006-203-227.176.6.pool.telefonica.de) (Read error: Connection reset by peer) |
| 2024-03-07 15:26:06 +0100 | <bwe> | [Leary]: I have functions `f :: a -> b -> c -> Errors [Text] d`. `caller = (\a b c -> f a b c) <$> f1 <*> f2 <*> f3`. |
| 2024-03-07 15:26:21 +0100 | <bwe> | f1 :: Errors [Text] Int |
| 2024-03-07 15:26:23 +0100 | euleritian | (~euleritia@77.22.252.56) |
| 2024-03-07 15:26:28 +0100 | danse-nr3 | (~danse@151.43.155.172) (Ping timeout: 268 seconds) |
| 2024-03-07 15:26:45 +0100 | <bwe> | f :: a -> b -> c -> Errors [Text] d |
| 2024-03-07 15:26:55 +0100 | <bwe> | caller :: Errors [Text] Int |
| 2024-03-07 15:27:13 +0100 | <bwe> | Can I get away with only Applicative? |
| 2024-03-07 15:27:50 +0100 | <bwe> | [Leary]: calling `f` in the lambda does not compile for me. |
| 2024-03-07 15:28:26 +0100 | danse-nr3 | (~danse@151.43.155.172) |
| 2024-03-07 15:29:50 +0100 | tri | (~tri@ool-18bbef1a.static.optonline.net) |
| 2024-03-07 15:30:39 +0100 | fmd | (~fmd@user/framend) |
| 2024-03-07 15:31:55 +0100 | alexherbo2 | (~alexherbo@2a02-8440-3241-19d1-2046-7c34-1287-cba1.rev.sfr.net) (Remote host closed the connection) |
| 2024-03-07 15:33:16 +0100 | alexherbo2 | (~alexherbo@2a02-8440-3241-19d1-6ced-529c-e3c8-d34a.rev.sfr.net) |
| 2024-03-07 15:34:12 +0100 | <[Leary]> | Nope---you'll end up with `Errors [Text] (Errors [Text] d)`. Collapsing that down to `Errors [Text] d` is precisely what Monad is for. Forgetting about typeclasses for a moment, if what you have on hand is only `Left outerErrs`, the inner errors never even happen, so there's no sense in trying to merge them in. |
| 2024-03-07 15:34:47 +0100 | tri | (~tri@ool-18bbef1a.static.optonline.net) (Ping timeout: 264 seconds) |
| 2024-03-07 15:34:58 +0100 | L29Ah | (~L29Ah@wikipedia/L29Ah) |
| 2024-03-07 15:35:07 +0100 | <bwe> | [Leary]: so, it's actually a nice example for bumping into Monad -- I had this feeling yesterday. |
| 2024-03-07 15:36:03 +0100 | marinelli | (~weechat@gateway/tor-sasl/marinelli) (Quit: marinelli) |
| 2024-03-07 15:36:45 +0100 | alexherbo2 | (~alexherbo@2a02-8440-3241-19d1-6ced-529c-e3c8-d34a.rev.sfr.net) (Remote host closed the connection) |
| 2024-03-07 15:36:48 +0100 | Unicorn_Princess | (~Unicorn_P@user/Unicorn-Princess/x-3540542) |
| 2024-03-07 15:37:12 +0100 | tr_ev | (~trev@user/trev) |
| 2024-03-07 15:37:26 +0100 | <bwe> | [Leary]: I am not sure whether I've got you right: Can I implement a Monad that does not break execution on encountering first error? |
| 2024-03-07 15:37:48 +0100 | <bwe> | [Leary]: What do I really want here? |
| 2024-03-07 15:37:58 +0100 | __monty__ | (~toonn@user/toonn) (Ping timeout: 255 seconds) |
| 2024-03-07 15:39:52 +0100 | <probie> | bwe: Only if your "monad" can effectively implement `m () -> (a -> m b) -> m b` |
| 2024-03-07 15:39:58 +0100 | __monty__ | (~toonn@user/toonn) |
| 2024-03-07 15:41:06 +0100 | <[Leary]> | You can, but not on top of Either. As I said above, see 'monad-chronicle' <https://hackage.haskell.org/package/monad-chronicle> or even just Writer. |
| 2024-03-07 15:42:43 +0100 | <danse-nr3> | yeah i think the issue here is trying to build on top of Either. I vaguely recall the concept of a "logger monad", but not sure what it has different from a writer |
| 2024-03-07 15:43:26 +0100 | euleritian | (~euleritia@77.22.252.56) (Ping timeout: 268 seconds) |
| 2024-03-07 15:43:29 +0100 | <bwe> | [Leary]: so what is https://hackage.haskell.org/package/monad-validate-1.3.0.0/docs/Control-Monad-Validate.html doing, then? |
| 2024-03-07 15:43:52 +0100 | CiaoSen | (~Jura@2a05:5800:2ad:4600:e6b9:7aff:fe80:3d03) (Quit: CiaoSen) |
| 2024-03-07 15:44:22 +0100 | <[Leary]> | Something fancier. Ignore it for now. |
| 2024-03-07 15:44:44 +0100 | <bwe> | [Leary]: https://hackage.haskell.org/package/validation is only Applicative, hence it does not cover the Monad case I need. |
| 2024-03-07 15:45:28 +0100 | <bwe> | [Leary]: …still trying to grasp what `these` does. |
| 2024-03-07 15:45:40 +0100 | euleritian | (~euleritia@dynamic-176-006-203-227.176.6.pool.telefonica.de) |
| 2024-03-07 15:45:48 +0100 | CiaoSen | (~Jura@2a05:5800:2ad:4600:e6b9:7aff:fe80:3d03) |
| 2024-03-07 15:48:01 +0100 | __monty__ | (~toonn@user/toonn) (Ping timeout: 272 seconds) |
| 2024-03-07 15:50:22 +0100 | <bwe> | why do I need either-or-both data type to collect errors? I am fine with not getting the result value if there are any errors AS LONG AS I get all the errors and execution is not short-circuited (except for those functions that need intermediary values that could not be produced). |
| 2024-03-07 15:51:01 +0100 | tr_ev | (~trev@user/trev) (Quit: tr_ev) |
| 2024-03-07 15:51:16 +0100 | <bwe> | [Leary]: I've looked into the tests of `these` to get some idea, but I couldn't spot any examples that are simple and explain the usage for me. |
| 2024-03-07 15:51:57 +0100 | cfricke | (~cfricke@user/cfricke) (Quit: WeeChat 4.1.2) |
| 2024-03-07 15:52:38 +0100 | <danse-nr3> | these and These seem an unrelated topic |
| 2024-03-07 15:52:57 +0100 | <bwe> | so, what do I need then? |
| 2024-03-07 15:53:10 +0100 | <glguy> | You need These so you can collect intermediate errors without short circuiting |
| 2024-03-07 15:54:17 +0100 | <danse-nr3> | hmm maybe they came in the conversation while i was offline. Makes sense now |
| 2024-03-07 15:56:53 +0100 | <bwe> | ok, these and monad-chronicle are different animals - which do I want? or better, what's even simpler? is it just a writer monad? |
| 2024-03-07 15:59:32 +0100 | <bwe> | glguy: and why do I need for not short circuiting either-or-both? I get that the Monad short circuits for `Left e` case. For `Right b` we did not encounter an error at all. |
| 2024-03-07 15:59:41 +0100 | misterfish | (~misterfis@87.215.131.98) |
| 2024-03-07 16:00:20 +0100 | <bwe> | So we'd need a thing that holds the error and continues the computation, is that right? |
| 2024-03-07 16:01:41 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2024-03-07 16:02:06 +0100 | <danse-nr3> | well i guess there would be recoverable errors (These a b) and not-recoverable ones (This a). Probably chronicle abstracts over a writer you could roll by yourself |
| 2024-03-07 16:02:26 +0100 | tri | (~tri@ool-18bbef1a.static.optonline.net) |
| 2024-03-07 16:03:45 +0100 | jau_ | (~user@134.101.168.5.dynamic-pppoe.dt.ipv4.wtnet.de) |
| 2024-03-07 16:06:12 +0100 | jau | (~user@2a04:4540:7212:6d00:e5f3:df01:adee:2cc8) (Ping timeout: 256 seconds) |
| 2024-03-07 16:06:46 +0100 | tri | (~tri@ool-18bbef1a.static.optonline.net) (Ping timeout: 256 seconds) |
| 2024-03-07 16:08:43 +0100 | <glguy> | bwe: like your said, Left short circuits. Left also carries errors. If you want error and not short circuit you need Both |
| 2024-03-07 16:09:33 +0100 | <glguy> | I'm the case of Both the result is probably incomplete or wrong (when you're using it for error tracking like this) but that's up to how you've structured your program |
| 2024-03-07 16:10:56 +0100 | <danse-nr3> | was not familiar with Both. Seems equivalent to These |
| 2024-03-07 16:11:57 +0100 | <danse-nr3> | although probably better named :P |
| 2024-03-07 16:12:35 +0100 | <glguy> | I don't remember the name |
| 2024-03-07 16:13:08 +0100 | <glguy> | Oh, it's These not Both |
| 2024-03-07 16:13:25 +0100 | <glguy> | But anyway, the thing that was both types |
| 2024-03-07 16:13:58 +0100 | lortabac | (~lortabac@2a01:e0a:541:b8f0:55ab:e185:7f81:54a4) (Quit: WeeChat 4.1.1) |
| 2024-03-07 16:18:43 +0100 | azimut | (~azimut@gateway/tor-sasl/azimut) |
| 2024-03-07 16:18:53 +0100 | <haskellbridge> | <eldritchcookie> hello what is preferred a quantified constraint or a new method ? |
| 2024-03-07 16:19:24 +0100 | <haskellbridge> | <eldritchcookie> compdata has a HFunctor type |
| 2024-03-07 16:19:43 +0100 | <haskellbridge> | <eldritchcookie> *type class |
| 2024-03-07 16:21:28 +0100 | <haskellbridge> | <eldritchcookie> and it seems to me that by the definition it should have a quantified constraint forall f. Functor f => Functor (hf f) |
| 2024-03-07 16:26:58 +0100 | <bwe> | glguy: Alright, if `These a b` collects errors, it can't produce `b` result value. So, what happens then? Will it be swapped to `This a` once an unrecoverable error occurs, i.e. no further computation can be done, hence `b` can't be produced. |
| 2024-03-07 16:31:00 +0100 | <glguy> | Yeah, swap to the no result only error case and short circuit |
| 2024-03-07 16:35:04 +0100 | ski | (~ski@ext-1-033.eduroam.chalmers.se) (Remote host closed the connection) |
| 2024-03-07 16:35:12 +0100 | ski | (~ski@ext-1-033.eduroam.chalmers.se) |
| 2024-03-07 16:45:00 +0100 | puke | (~puke@user/puke) (Remote host closed the connection) |
| 2024-03-07 16:45:23 +0100 | puke | (~puke@user/puke) |
| 2024-03-07 16:47:22 +0100 | raehik | (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) (Ping timeout: 246 seconds) |
| 2024-03-07 16:49:06 +0100 | ski | (~ski@ext-1-033.eduroam.chalmers.se) (Ping timeout: 268 seconds) |
| 2024-03-07 16:49:20 +0100 | ski | (~ski@ext-1-033.eduroam.chalmers.se) |
| 2024-03-07 16:55:22 +0100 | euleritian | (~euleritia@dynamic-176-006-203-227.176.6.pool.telefonica.de) (Read error: Connection reset by peer) |
| 2024-03-07 16:55:41 +0100 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) |
| 2024-03-07 16:58:26 +0100 | ski | (~ski@ext-1-033.eduroam.chalmers.se) (Ping timeout: 252 seconds) |
| 2024-03-07 16:59:35 +0100 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Read error: Connection reset by peer) |
| 2024-03-07 16:59:47 +0100 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) |
| 2024-03-07 17:00:34 +0100 | misterfish | (~misterfis@87.215.131.98) (Ping timeout: 264 seconds) |
| 2024-03-07 17:00:40 +0100 | ski | (~ski@ext-1-033.eduroam.chalmers.se) |
| 2024-03-07 17:01:27 +0100 | euphores | (~SASL_euph@user/euphores) (Quit: Leaving.) |
| 2024-03-07 17:03:41 +0100 | srz | (~srz@181.228.49.93) (Ping timeout: 240 seconds) |
| 2024-03-07 17:04:05 +0100 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Ping timeout: 240 seconds) |
| 2024-03-07 17:05:37 +0100 | danse-nr3 | (~danse@151.43.155.172) (Read error: Connection reset by peer) |
| 2024-03-07 17:05:58 +0100 | danse-nr3 | (~danse@151.43.217.59) |
| 2024-03-07 17:08:23 +0100 | ski | (~ski@ext-1-033.eduroam.chalmers.se) (Ping timeout: 264 seconds) |
| 2024-03-07 17:08:59 +0100 | euphores | (~SASL_euph@user/euphores) |
| 2024-03-07 17:11:09 +0100 | raehik | (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) |
| 2024-03-07 17:11:13 +0100 | igemnace | (~ian@user/igemnace) (Quit: WeeChat 4.2.1) |
| 2024-03-07 17:12:31 +0100 | EvanR_ | EvanR |
| 2024-03-07 17:13:23 +0100 | <bwe> | glguy: That's a great start :). My first approach: https://gist.github.com/benjaminweb/0df0b7af1fef73caf47e5006b99a3a07 . If `f0` gives an error, it can't give a `These a b` value, because there is no `b`. However this `This` leads to short circuit `caller2`. I know I need to have `These a b` instead to not short circuit - but how if I don't have value `b`? |
| 2024-03-07 17:18:28 +0100 | <danse-nr3> | then it is a not-recoverable error, i guess |
| 2024-03-07 17:19:19 +0100 | <glguy> | bwe: You'll need to restructure your program so that it doesn't immediately depend on an unrecoverable error f0 |
| 2024-03-07 17:19:51 +0100 | <glguy> | if you have: do x <- f0; ..., then the whole ... depends on there being some x value |
| 2024-03-07 17:20:06 +0100 | <glguy> | If you're saying the whole thing depends on the result and you do'nt have one, then certainly that's when things stop |
| 2024-03-07 17:21:50 +0100 | azimut | (~azimut@gateway/tor-sasl/azimut) (Ping timeout: 260 seconds) |
| 2024-03-07 17:22:34 +0100 | causal | (~eric@50.35.85.7) (Quit: WeeChat 4.1.1) |
| 2024-03-07 17:22:37 +0100 | arahael | (~arahael@119-18-0-146.771200.syd.nbn.aussiebb.net) (Ping timeout: 264 seconds) |
| 2024-03-07 17:23:28 +0100 | <dminuoso> | bwe: So what I might want, is rather than shoehorning it into some monadic type like These, I would have some ambient `Env` data type with say `data Env = Env { warnings :: IORef [Warning], errors :: IORef [Error] }`, and then instead of using a singular >>, I would then develop a toolset of combinators that maybe shortcircuit or not, or maybe set errors (that at some later stage become fatal) |
| 2024-03-07 17:23:29 +0100 | <dminuoso> | while producing some default values (such that you can continue on and collect more errors) |
| 2024-03-07 17:23:35 +0100 | <glguy> | Two of your choices (maybe there are some more) are to either make up a value and report the error like the restricted sumAll could return the too-big number and record the error about it |
| 2024-03-07 17:23:52 +0100 | <glguy> | or to not use Monad for piecing together parts that are independent |
| 2024-03-07 17:24:01 +0100 | azimut | (~azimut@gateway/tor-sasl/azimut) |
| 2024-03-07 17:24:27 +0100 | <glguy> | Switching to using IO won't change the problems you have to solve |
| 2024-03-07 17:24:57 +0100 | <glguy> | it's just a different mechanism for storing the errors |
| 2024-03-07 17:25:52 +0100 | <bwe> | Well, I am thinking of just making inputs and outputs same: Errors [Text] Int -> Errors [Text] Int |
| 2024-03-07 17:26:04 +0100 | <EvanR> | STM can be nice for piecing together parts that are independent |
| 2024-03-07 17:26:09 +0100 | <EvanR> | STM all the things |
| 2024-03-07 17:26:36 +0100 | <glguy> | It's not obvious to me how STM helps in this case of validation and error gathering, but it's certainly useful in general |
| 2024-03-07 17:26:54 +0100 | <EvanR> | didn't read the context sorry |
| 2024-03-07 17:27:14 +0100 | <dminuoso> | glguy: Oh it can actually simplify things since it gives you sequentiality, possibility of diagnostics - and the question of "errors" (fatal, or fatal at some delayed time) is a matter of simple `IO a -> IO b -> IO b` combinators. |
| 2024-03-07 17:27:15 +0100 | <glguy> | bwe: you should be able to build what you want not using any typeclasses at all |
| 2024-03-07 17:27:28 +0100 | <glguy> | dminuoso: No, I don't think it changes the problem in any way |
| 2024-03-07 17:27:51 +0100 | <dminuoso> | glguy: Well, it does for me *shrugs*. |
| 2024-03-07 17:27:54 +0100 | <glguy> | You still have to deal with all the same questions |
| 2024-03-07 17:28:29 +0100 | kuribas | (~user@ip-188-118-57-242.reverse.destiny.be) (Read error: Connection reset by peer) |
| 2024-03-07 17:28:50 +0100 | <bwe> | Let's simplify: I've got two feeder functions `f1` and `f2`. Both get called before `final` which consumes both. If `f1` and `f2` raise an error, both should be returned. In that case `final` cannot be called. If they don't raise an error, `final` might. |
| 2024-03-07 17:29:12 +0100 | <glguy> | bwe: try writing what you want directly |
| 2024-03-07 17:29:18 +0100 | <glguy> | just write some functions that do the thing you want |
| 2024-03-07 17:29:23 +0100 | <dminuoso> | The point really is, rather than trying to encode special error behavior into a type, its easier to just encode it into a simple `case-of` one way or another. |
| 2024-03-07 17:29:40 +0100 | <dminuoso> | So I guess we're after the same thing here, glguy. |
| 2024-03-07 17:30:05 +0100 | <glguy> | once you have it working "manually" you can look to see if the behaviors you desire correspond to any of the premade stuff |
| 2024-03-07 17:30:21 +0100 | <glguy> | you'll get more clarity about how it should work at all that way |
| 2024-03-07 17:31:09 +0100 | <glguy> | What you're doing seems "obvious" to me because I've already done it manually before |
| 2024-03-07 17:32:33 +0100 | <glguy> | after that you'll probably find correspondence between things you've done in your manual code inside things like the Monad instances for the Validate and These types and you'll be more prepared recognize the patterns |
| 2024-03-07 17:33:34 +0100 | <bwe> | glguy: does that include the case idea by dminuoso? |
| 2024-03-07 17:33:45 +0100 | <EvanR> | does "parse don't validate" apply |
| 2024-03-07 17:34:24 +0100 | <glguy> | bwe: If writing out your own cases on the different constructors is dminuoso's idea, then yes |
| 2024-03-07 17:34:46 +0100 | <dminuoso> | EvanR: So in our SDN compiler we can do both. Its just that that most types here have a UselessDefault instance we can use to make up nonsense values for no purpose other than to carry on to collect further errors. |
| 2024-03-07 17:34:55 +0100 | <glguy> | EvanR: I think that's the space we're in, but usually that phrase means you shouldn't just check a value is good, you should transform it into a type that only holds good values |
| 2024-03-07 17:34:59 +0100 | ski | (~ski@ext-1-033.eduroam.chalmers.se) |
| 2024-03-07 17:35:10 +0100 | <glguy> | EvanR: in this case the topic is that along the way we'd like to provide as much feedback as possible |
| 2024-03-07 17:35:16 +0100 | <dminuoso> | (And they are special values that are identified in assertion passes, just to make sure we dont accidentally leak them out) |
| 2024-03-07 17:35:25 +0100 | <glguy> | so don't abort parsing any earlier than you absolutely have ot |
| 2024-03-07 17:35:43 +0100 | <EvanR> | yeah, find more problems with the input than 1 |
| 2024-03-07 17:35:46 +0100 | <EvanR> | potentially |
| 2024-03-07 17:36:06 +0100 | <glguy> | sometimes you find errors that only happened *because* you didn't stop at the first error, but ideally that's the less common case :) |
| 2024-03-07 17:36:11 +0100 | <dminuoso> | And by module structure, you generally cant accidentally conjure "non-sense values" here other than by `configErrorDef` which automatically sets a fatal error in the compiler environment. |
| 2024-03-07 17:36:21 +0100 | <dminuoso> | So.. does that satisfy "parse dont validate"? Id say sure. |
| 2024-03-07 17:36:50 +0100 | <c_wraith> | glguy: it's not less common when using C++! I had GCC report several thousand errors in a hundred line program because of one missing semicolon! |
| 2024-03-07 17:36:52 +0100 | machinedgod | (~machinedg@d173-183-246-216.abhsia.telus.net) (Ping timeout: 260 seconds) |
| 2024-03-07 17:37:47 +0100 | <dminuoso> | c_wraith: It's a difficult thing to have parser work with incorrect syntax I supose. |
| 2024-03-07 17:38:24 +0100 | <dminuoso> | My feeling says there has got to be published research on "recovering" after syntax errors. |
| 2024-03-07 17:38:26 +0100 | <c_wraith> | dminuoso: also when templates get involved, they can really make your syntax errors happen replicate over and over. |
| 2024-03-07 17:39:36 +0100 | <c_wraith> | dminuoso: have you use uu-parsinglib? It's an interesting experiment. In the case of parse errors, it reports the error then proceeds as if it had found whatever it was expecting. |
| 2024-03-07 17:40:47 +0100 | <dminuoso> | Ah another output of Utrecht, it is quite interesting how much research is done in NL. |
| 2024-03-07 17:47:36 +0100 | <danse-nr3> | supporting science since galileo's times |
| 2024-03-07 17:53:27 +0100 | <bwe> | glguy, dminuoso: https://gist.github.com/benjaminweb/0df0b7af1fef73caf47e5006b99a3a07#file-mylib-hs-L36-L47 |
| 2024-03-07 17:54:05 +0100 | <glguy> | bwe: looks like you kind of cheated by moving f0 to the bottom, right? |
| 2024-03-07 17:54:36 +0100 | <bwe> | glguy: earlier, yes; but ignore caller2 as of now, I've changed caller1 |
| 2024-03-07 17:54:55 +0100 | <dminuoso> | That all looks rather.. arbitrary. |
| 2024-03-07 17:55:18 +0100 | <dminuoso> | This looks like an XY problem. |
| 2024-03-07 17:55:54 +0100 | <dminuoso> | Without seeing the actual problem domain such that `this`, `that`, `f0`, `f1` and `f2` make any sense, its really tough to give any advice how to approach this. |
| 2024-03-07 17:56:47 +0100 | <bwe> | Let's simplify: I've got two feeder functions `f1` and `f2`. Both get called before `final` which consumes both. If `f1` and `f2` raise an error, both should be returned. In that case `final` cannot be called. If they don't raise an error, `final` might. |
| 2024-03-07 17:57:04 +0100 | <bwe> | dminuoso: Well, that's my problem statement I've posted earlier. |
| 2024-03-07 17:57:27 +0100 | Tuplanolla | (~Tuplanoll@91-159-69-59.elisa-laajakaista.fi) |
| 2024-03-07 17:57:40 +0100 | <dminuoso> | bwe: Write the code exactly like you described it. |
| 2024-03-07 17:58:24 +0100 | <dminuoso> | Not quite sure what "both should be returend [if f1 and f2 raise an error]" means |
| 2024-03-07 17:58:30 +0100 | <dminuoso> | both what? |
| 2024-03-07 17:58:41 +0100 | <probie> | both errors |
| 2024-03-07 17:58:49 +0100 | <dminuoso> | And if only one returns an error?> |
| 2024-03-07 17:58:54 +0100 | sidd-dino | (~sidd-dino@gateway/tor-sasl/sidd-dino) (Remote host closed the connection) |
| 2024-03-07 17:59:01 +0100 | <bwe> | any errors of f1 and f2 should be accumulated and returned |
| 2024-03-07 17:59:26 +0100 | _ht | (~Thunderbi@28-52-174-82.ftth.glasoperator.nl) |
| 2024-03-07 18:00:51 +0100 | <dminuoso> | bwe: Yeah, so in my compiler I have these primitives: https://gist.github.com/dminuoso/421ab94f671c010d213592dc09af82daf |
| 2024-03-07 18:01:15 +0100 | <bwe> | dminuoso: link is dead |
| 2024-03-07 18:01:16 +0100 | <dminuoso> | Maybe this approach can help you *shrugs* |
| 2024-03-07 18:01:21 +0100 | <dminuoso> | Sorry https://gist.github.com/dminuoso/421ab94f671c010d213592dc09af82da |
| 2024-03-07 18:01:31 +0100 | <dminuoso> | Not sure where that trailing f came from |
| 2024-03-07 18:02:37 +0100 | <bwe> | glguy: is the current implementation of`caller1` the manual way you meant? |
| 2024-03-07 18:04:16 +0100 | destituion | (~destituio@2a02:2121:650:17b6:2818:3a8c:bceb:d3de) |
| 2024-03-07 18:04:31 +0100 | <dminuoso> | bwe: Anyway, all of this is only useful if this kind of error handling is a recurring theme for you. |
| 2024-03-07 18:04:41 +0100 | <dminuoso> | otoh if its a one-off, I wouldnt add a dependency either. |
| 2024-03-07 18:05:23 +0100 | <EvanR> | halt and catch fire |
| 2024-03-07 18:05:27 +0100 | <EvanR> | there's your error handling |
| 2024-03-07 18:05:35 +0100 | <EvanR> | in many trending languages now a days |
| 2024-03-07 18:06:13 +0100 | <dminuoso> | Ive just become a fan of IO. *shrugs* |
| 2024-03-07 18:06:17 +0100 | <dminuoso> | It makes so many things so easy. |
| 2024-03-07 18:06:22 +0100 | <dminuoso> | Collecting state, logging, throwing exceptions... |
| 2024-03-07 18:06:45 +0100 | <dminuoso> | All the stuff that otherwise introduces large piles of dependency trees, illegible type errors, and unwieldy type signatures. |
| 2024-03-07 18:07:12 +0100 | <dminuoso> | IO - the forgotten monad. |
| 2024-03-07 18:07:22 +0100 | <bwe> | What's so hard in accumulating errors? Short circuit only if a function call receives an error value as value. But then return all errors accumulated since. |
| 2024-03-07 18:07:33 +0100 | <dminuoso> | bwe: Absolutely nothing! I just accumulate them in an IORef! |
| 2024-03-07 18:08:10 +0100 | <bwe> | I am almost about to escape to write Python! |
| 2024-03-07 18:08:58 +0100 | <bwe> | dminuoso: why can't this be automatic behaviour in my function using the Monad of that error collecting container? |
| 2024-03-07 18:09:41 +0100 | <dminuoso> | bwe: what do you mean by "automatic behavior"? |
| 2024-03-07 18:09:46 +0100 | <dminuoso> | IO *is* that behavior. |
| 2024-03-07 18:10:35 +0100 | ubert | (~Thunderbi@2a02:8109:ab8a:5a00:e52f:c589:18bb:7d17) (Quit: ubert) |
| 2024-03-07 18:10:37 +0100 | <bwe> | dminuoso: collect error to error stack on error, short-circuit on error used as argument in function call, then return error stack. |
| 2024-03-07 18:10:44 +0100 | <bwe> | dminuoso: why do I need IO for this? |
| 2024-03-07 18:10:51 +0100 | <EvanR> | Writer can also be used to accumulate errors |
| 2024-03-07 18:11:23 +0100 | <EvanR> | if that's all your code is dedicated to doing |
| 2024-03-07 18:11:26 +0100 | <bwe> | but I mean, what's the recommended way to do this? |
| 2024-03-07 18:12:09 +0100 | <EvanR> | when you really know what your code is trying to do, you can use the most appropriate abstraction if it exists, or write a custom type |
| 2024-03-07 18:12:17 +0100 | <EvanR> | which is how GHC works |
| 2024-03-07 18:12:30 +0100 | redmp | (~redmp@mobile-166-171-248-17.mycingular.net) |
| 2024-03-07 18:12:31 +0100 | <EvanR> | if you don't know what your code is trying to do, IO helps |
| 2024-03-07 18:12:52 +0100 | <EvanR> | but it's a strictly worse situation to be in |
| 2024-03-07 18:14:25 +0100 | <bwe> | I need a way to not let the computation to short circuit when feeder functions have errors. I need a way to let the computation short circuit once a value is tried to be consumed that is an error value. |
| 2024-03-07 18:14:38 +0100 | <bwe> | EvanR: does Writer solve my need here? |
| 2024-03-07 18:14:50 +0100 | <EvanR> | no I thought you were just trying to accumulate error messages |
| 2024-03-07 18:15:06 +0100 | <bwe> | EvanR: so, what do I need? |
| 2024-03-07 18:15:14 +0100 | tzh | (~tzh@c-73-164-206-160.hsd1.or.comcast.net) |
| 2024-03-07 18:15:18 +0100 | <EvanR> | short circuiting? That's Maybe or Either |
| 2024-03-07 18:15:38 +0100 | <bwe> | glguy: I've searched for some time on gh to find some examples using These to no avail. |
| 2024-03-07 18:16:19 +0100 | <bwe> | EvanR: We've been through that before, Left of either forces Monad to short circuit on each error. I need it NOT to short circuit on error. |
| 2024-03-07 18:16:28 +0100 | <EvanR> | > liftA2 (+) (Just 2) (Just 2) |
| 2024-03-07 18:16:30 +0100 | <lambdabot> | Just 4 |
| 2024-03-07 18:16:34 +0100 | <EvanR> | > liftA2 (+) (Just 2) Nothing |
| 2024-03-07 18:16:35 +0100 | <lambdabot> | Nothing |
| 2024-03-07 18:16:49 +0100 | <EvanR> | you want to not short circuit? that's what I thought |
| 2024-03-07 18:16:55 +0100 | <glguy> | bwe: These has three cases: Short-circuit with error, Don't short-circuit but also error, Don't short-circuit and no error |
| 2024-03-07 18:16:56 +0100 | L29Ah | (~L29Ah@wikipedia/L29Ah) () |
| 2024-03-07 18:17:20 +0100 | <glguy> | bwe: Most people probably don't use the "these" package, they just write this stuff out manually. The these package doesn't offer that much benefit as a dependency |
| 2024-03-07 18:17:47 +0100 | <bwe> | EvanR: https://gist.github.com/benjaminweb/fef460aad1e799f415e25389f9c13783 https://gist.github.com/benjaminweb/0df0b7af1fef73caf47e5006b99a3a07 |
| 2024-03-07 18:17:49 +0100 | redmp | (~redmp@mobile-166-171-248-17.mycingular.net) (Ping timeout: 264 seconds) |
| 2024-03-07 18:18:37 +0100 | <bwe> | glguy: Don't short-circuit but also error -> previous errors collected on the way didn't prevent from calculating result value. |
| 2024-03-07 18:19:04 +0100 | <EvanR> | so there's no short circuiting anywhere |
| 2024-03-07 18:19:10 +0100 | <glguy> | yeah, even if that result value is flawed for the reasons listed in theerrors |
| 2024-03-07 18:19:22 +0100 | redmp | (~redmp@mobile-166-137-178-225.mycingular.net) |
| 2024-03-07 18:19:35 +0100 | <glguy> | EvanR: I think bwe wants to avoid short-circuiting when possible, but sometimes that's not possible |
| 2024-03-07 18:20:01 +0100 | <bwe> | glguy: sometimes: a function tries to use a value that couldn't been produced, i.e. is an error value. |
| 2024-03-07 18:20:19 +0100 | <glguy> | bwe: in that case you want to short-circuit |
| 2024-03-07 18:20:30 +0100 | <bwe> | glguy: exactly |
| 2024-03-07 18:20:45 +0100 | <EvanR> | here's another pattern |
| 2024-03-07 18:20:50 +0100 | <EvanR> | :t partition |
| 2024-03-07 18:20:51 +0100 | <lambdabot> | (a -> Bool) -> [a] -> ([a], [a]) |
| 2024-03-07 18:20:57 +0100 | <EvanR> | :t partitionEithers |
| 2024-03-07 18:20:58 +0100 | <lambdabot> | [Either a b] -> ([a], [b]) |
| 2024-03-07 18:21:18 +0100 | <EvanR> | if you analyize a list of things into yes values and no errors, you can sort them and use the yes values, and have the errors |
| 2024-03-07 18:22:01 +0100 | <bwe> | glguy: but what if `c` gets produced before `f` is called (that takes in `a` and `b`) - in that case c has an error? |
| 2024-03-07 18:22:27 +0100 | <bwe> | glguy: we can result a `These [c] d` -- d being result of f |
| 2024-03-07 18:23:23 +0100 | danse-nr3 | (~danse@151.43.217.59) (Ping timeout: 264 seconds) |
| 2024-03-07 18:23:46 +0100 | chele | (~chele@user/chele) (Remote host closed the connection) |
| 2024-03-07 18:24:43 +0100 | manwithluck | (manwithluc@gateway/vpn/protonvpn/manwithluck) (Ping timeout: 260 seconds) |
| 2024-03-07 18:25:09 +0100 | <glguy> | I'm lost in the alphabet, I think |
| 2024-03-07 18:25:21 +0100 | manwithluck | (manwithluc@gateway/vpn/protonvpn/manwithluck) |
| 2024-03-07 18:25:42 +0100 | <glguy> | But if f is a function, and it *depends* on a previous computation succeeding because it needs that result to be the function argument, then obviously it can only work if there's a function argument |
| 2024-03-07 18:25:52 +0100 | notzmv | (~daniel@user/notzmv) (Ping timeout: 260 seconds) |
| 2024-03-07 18:26:05 +0100 | <glguy> | If it could work without one then it shouldn't be a function |
| 2024-03-07 18:26:38 +0100 | <ncf> | abcdef[you are here]hij |
| 2024-03-07 18:30:25 +0100 | tri | (~tri@ool-18bbef1a.static.optonline.net) |
| 2024-03-07 18:31:37 +0100 | econo_ | (uid147250@id-147250.tinside.irccloud.com) |
| 2024-03-07 18:34:48 +0100 | tri | (~tri@ool-18bbef1a.static.optonline.net) (Ping timeout: 255 seconds) |
| 2024-03-07 18:35:51 +0100 | rvalue | (~rvalue@user/rvalue) (Ping timeout: 272 seconds) |
| 2024-03-07 18:39:47 +0100 | <bwe> | https://gist.github.com/benjaminweb/9a9664625f2ba30d14fc0a338dc8a601 <- desired behaviour is described with tests and comments. |
| 2024-03-07 18:40:00 +0100 | <bwe> | (I am persevering…) |
| 2024-03-07 18:40:15 +0100 | notzmv | (~daniel@user/notzmv) |
| 2024-03-07 18:42:29 +0100 | <bwe> | What I want is that the Monad handles that for me. |
| 2024-03-07 18:43:01 +0100 | <glguy> | bwe: these are examples I'm imagining https://gist.github.com/glguy/e048cf88a20b2fad8df1917bcc1538b9 |
| 2024-03-07 18:43:09 +0100 | <glguy> | When it comes to a Monad helping you, you will need to use two different types |
| 2024-03-07 18:43:28 +0100 | <glguy> | One is a Monad that short-circuits and another is merely an Applicative that perseveres |
| 2024-03-07 18:43:55 +0100 | <glguy> | The Monad will never be able to persevere in the face of a fatal error |
| 2024-03-07 18:44:13 +0100 | Square | (~Square@user/square) |
| 2024-03-07 18:44:14 +0100 | <glguy> | because >>= has a function that relies on there being an argument to apply the function to |
| 2024-03-07 18:44:48 +0100 | <glguy> | but an applicative <*> can gather up errors from both of its arguments |
| 2024-03-07 18:45:16 +0100 | <bwe> | ah. I want applicative behaviour from a monad. that causes the frustration. |
| 2024-03-07 18:45:31 +0100 | <glguy> | or if you don't want to use two types, don't make your thing a monad but provide a manual, non >>= function that does what >>= for when you wanted that behavior |
| 2024-03-07 18:45:41 +0100 | rvalue | (~rvalue@user/rvalue) |
| 2024-03-07 18:46:24 +0100 | <bwe> | glguy: are you getting the idea of what I am trying to accomplish with my last gist? |
| 2024-03-07 18:47:07 +0100 | <glguy> | bwe: the thing you want on line 18 is too magical for you to get it using Monad |
| 2024-03-07 18:47:47 +0100 | <glguy> | You made line 18 "need" c by virtue of you putting it below line 17 |
| 2024-03-07 18:48:47 +0100 | L29Ah | (~L29Ah@wikipedia/L29Ah) |
| 2024-03-07 18:49:56 +0100 | <haskellbridge> | <eldritchcookie> uh don't you want callCC? |
| 2024-03-07 18:50:11 +0100 | <bwe> | glguy: Fine. So delete line 17. if 15 (a) is an error, b should still be processed. short circuit only once `f` tries to pull in `a` and `b`.i |
| 2024-03-07 18:50:39 +0100 | <glguy> | bwe: if you write a <- getA; ... |
| 2024-03-07 18:50:48 +0100 | <glguy> | then everything after that depends on a |
| 2024-03-07 18:51:11 +0100 | <glguy> | If you want that not to be true you need to not use a Monad. You could still get do-notation using ApplicativeDo |
| 2024-03-07 18:51:33 +0100 | <bwe> | glguy: so ApplicativeDo is what I need |
| 2024-03-07 18:52:13 +0100 | <glguy> | bwe: using applicativedo to do this kind of validation is what I'm using here https://glguy.net/config-demo/ |
| 2024-03-07 18:52:38 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2024-03-07 18:53:11 +0100 | <bwe> | glguy: does These take care of accumulating the errors on the way using ApplicativeDo? |
| 2024-03-07 18:53:24 +0100 | <glguy> | bwe: no, because it has a Monad instance |
| 2024-03-07 18:53:37 +0100 | <glguy> | and an Applicative instance needs to agree with the Monad instance |
| 2024-03-07 18:53:42 +0100 | <bwe> | glguy: so, I shouldn't use These for my situation, right? |
| 2024-03-07 18:54:17 +0100 | <glguy> | You shouldn't use These with ApplicativeDo. for that you'd need a different type or just a newtype around These for when you're doing the do-notation parts |
| 2024-03-07 18:56:33 +0100 | <bwe> | what do I need then to have the errors accumulate? and short circuiting only once the function tries to use a value that is an error value should be default, or? |
| 2024-03-07 18:57:10 +0100 | drdo8 | (~drdo@bl5-29-74.dsl.telepac.pt) |
| 2024-03-07 18:57:50 +0100 | <haskellbridge> | <eldritchcookie> uh why are the semantics of MonadThrow wrong for your use case? |
| 2024-03-07 18:57:51 +0100 | drdo | (~drdo@bl5-29-74.dsl.telepac.pt) (Ping timeout: 260 seconds) |
| 2024-03-07 18:57:51 +0100 | drdo8 | drdo |
| 2024-03-07 19:01:55 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2024-03-07 19:02:56 +0100 | tri | (~tri@ool-18bbef1a.static.optonline.net) |
| 2024-03-07 19:03:19 +0100 | srz | (~srz@181.228.49.93) |
| 2024-03-07 19:03:27 +0100 | thailigur | (~thailigur@94.182.126.244) |
| 2024-03-07 19:03:39 +0100 | <ncf> | your monadic sequencing is expressing that the computation `f a b` might depend on the values of a, b, and c. you can't really detect that `f a b` isn't using c within the Monad interface |
| 2024-03-07 19:03:59 +0100 | <ncf> | you'd have to somehow parallelise A+B and C |
| 2024-03-07 19:05:14 +0100 | <dolio> | It doesn't matter that `f a b` doesn't. The overall computation does. |
| 2024-03-07 19:06:07 +0100 | eldritch_cookie | (~Srain@177.132.38.123) |
| 2024-03-07 19:06:40 +0100 | <eldritch_cookie> | hello apparently the matrix bridge is broken so i was just screaming into the void... |
| 2024-03-07 19:06:53 +0100 | tri | (~tri@ool-18bbef1a.static.optonline.net) (Ping timeout: 240 seconds) |
| 2024-03-07 19:07:03 +0100 | <glguy> | eldritch_cookie: your message about MonadThrow came through |
| 2024-03-07 19:07:31 +0100 | <glguy> | and then an earlier one about callCC, but I don't know what either had to do with bwe's question |
| 2024-03-07 19:08:09 +0100 | zetef | (~quassel@95.77.17.251) (Ping timeout: 272 seconds) |
| 2024-03-07 19:08:59 +0100 | <haskellbridge> | <eldritchcookie> ok ??? isn't the problem that he wants shortcircuit evaluation?? |
| 2024-03-07 19:09:05 +0100 | <haskellbridge> | <geekosaur> your messages appeaed on both sides of the bridge; what did you think went wrong? |
| 2024-03-07 19:10:36 +0100 | <glguy> | eldritch_cookie: the overall topic is about avoiding short-circuiting when possible |
| 2024-03-07 19:10:37 +0100 | bontaq``` | (~user@165.1.205.230) |
| 2024-03-07 19:11:01 +0100 | <haskellbridge> | <eldritchcookie> huh? |
| 2024-03-07 19:11:14 +0100 | <haskellbridge> | <eldritchcookie> doesn't void $ getC work? |
| 2024-03-07 19:11:49 +0100 | pavonia | (~user@user/siracusa) (Quit: Bye!) |
| 2024-03-07 19:11:54 +0100 | <haskellbridge> | <eldritchcookie> i see no reason why you would call getC not use its bound value and not want any side effects? |
| 2024-03-07 19:12:14 +0100 | bontaq`` | (~user@ool-45779c03.dyn.optonline.net) (Read error: Connection reset by peer) |
| 2024-03-07 19:13:56 +0100 | <haskellbridge> | <eldritchcookie> geekousaur: i my earlier message was ignored, i then read the text on the top of the screen so i just assumed my message never went through, |
| 2024-03-07 19:15:59 +0100 | bontaq``` | (~user@165.1.205.230) (Ping timeout: 256 seconds) |
| 2024-03-07 19:16:04 +0100 | <haskellbridge> | <eldritchcookie> i guess i was having the wrong expectations on discord even if you don't understand why it isn't related to the conversation you still respond |
| 2024-03-07 19:19:46 +0100 | target_i | (~target_i@user/target-i/x-6023099) |
| 2024-03-07 19:21:36 +0100 | gmg | (~user@user/gehmehgeh) (Quit: Leaving) |
| 2024-03-07 19:21:41 +0100 | thailigur | (~thailigur@94.182.126.244) (Quit: Client closed) |
| 2024-03-07 19:28:58 +0100 | waleee | (~waleee@h-176-10-144-38.NA.cust.bahnhof.se) |
| 2024-03-07 19:31:04 +0100 | euphores | (~SASL_euph@user/euphores) (Ping timeout: 255 seconds) |
| 2024-03-07 19:32:25 +0100 | CiaoSen | (~Jura@2a05:5800:2ad:4600:e6b9:7aff:fe80:3d03) (Ping timeout: 256 seconds) |
| 2024-03-07 19:37:26 +0100 | euphores | (~SASL_euph@user/euphores) |
| 2024-03-07 19:50:05 +0100 | srz | (~srz@181.228.49.93) (Ping timeout: 240 seconds) |
| 2024-03-07 19:50:08 +0100 | <dminuoso> | 17:12:52 EvanR │ but it's a strictly worse situation to be in |
| 2024-03-07 19:50:39 +0100 | <EvanR> | not knowing what you're supposed to be doing, not IO |
| 2024-03-07 19:50:39 +0100 | <dminuoso> | I somewhat disagree with that. Shoehorning all your effects into the type system just to avoid that general IO type seems more like a religious choice, especially because of all the pain that it often entails. |
| 2024-03-07 19:51:02 +0100 | <dminuoso> | The effects are either simple and non-composable, or they are composable and very complicated. |
| 2024-03-07 19:51:22 +0100 | <dminuoso> | Simple and composable effects is not something we have in Haskell. |
| 2024-03-07 19:51:42 +0100 | <EvanR> | on all the advanced solutions to do stuff in IO it seems a lot of times just IO would be simpler |
| 2024-03-07 19:51:55 +0100 | <EvanR> | but when IO is not involved I don't know |
| 2024-03-07 19:51:56 +0100 | <monochrom> | https://www.vex.net/~trebla/haskell/exception.xhtml :) |
| 2024-03-07 19:54:02 +0100 | <haskellbridge> | <eldritchcookie> dminuoso: i will have to disagree, i find Effectful quite simple, though if you want to escape IO with it you need a lot of boilerplate |
| 2024-03-07 19:54:39 +0100 | <haskellbridge> | <eldritchcookie> https://hackage.haskell.org/package/effectful |
| 2024-03-07 19:56:24 +0100 | destituion | (~destituio@2a02:2121:650:17b6:2818:3a8c:bceb:d3de) (Ping timeout: 260 seconds) |
| 2024-03-07 19:56:39 +0100 | srz | (~srz@181.228.49.93) |
| 2024-03-07 19:57:53 +0100 | srz | (~srz@181.228.49.93) (Remote host closed the connection) |
| 2024-03-07 19:58:29 +0100 | <monochrom> | I'm going to go on a hyperbole and say that I find category theory quite simple too. To prove that if I forgot how much maturity I needed before higher abstractions became simple to me, I would end up giving very derailing advice to beginners. |
| 2024-03-07 19:59:40 +0100 | <monochrom> | (I spent a year on universal algebra before I heard of category theory. So yeah of course the latter looks so obvious under the circumstance.) |
| 2024-03-07 20:00:09 +0100 | <int-e> | monochrom: "To understand Haskell, you must first understand adjunctions." |
| 2024-03-07 20:00:15 +0100 | <monochrom> | hahaha |
| 2024-03-07 20:00:47 +0100 | <int-e> | (which btw never clicked for me) |
| 2024-03-07 20:01:06 +0100 | srz | (~srz@181.228.49.93) |
| 2024-03-07 20:01:21 +0100 | tri | (~tri@ool-18bbef1a.static.optonline.net) |
| 2024-03-07 20:02:01 +0100 | srz | (~srz@181.228.49.93) (Remote host closed the connection) |
| 2024-03-07 20:02:47 +0100 | <monochrom> | I also spent a year on lattice theory and Galois adjunctions before I heard of category theory. Even then, I avoided learning category's adjunction (because I hadn't needed it for a long time) until recently. |
| 2024-03-07 20:03:39 +0100 | <monochrom> | (Galois adjunction just means the two categories are just partial orders, so everything is simpler and a few things trivialized.) |
| 2024-03-07 20:04:48 +0100 | <monochrom> | The paper that finally demanded me to finally learn category's adjunctions seriously is Ralf Hinze's Adjoint Folds And Unfolds. |
| 2024-03-07 20:05:30 +0100 | <monochrom> | Oh it also uses Yoneda lemma and Kan extensions and ends and coends, so I am going into that rabbit hole these few weeks. |
| 2024-03-07 20:05:58 +0100 | tri | (~tri@ool-18bbef1a.static.optonline.net) (Ping timeout: 264 seconds) |
| 2024-03-07 20:06:52 +0100 | dcoutts | (~duncan@cpc69402-oxfd27-2-0-cust903.4-3.cable.virginm.net) (Remote host closed the connection) |
| 2024-03-07 20:07:15 +0100 | dcoutts | (~duncan@cpc69402-oxfd27-2-0-cust903.4-3.cable.virginm.net) |
| 2024-03-07 20:10:50 +0100 | misterfish | (~misterfis@84.53.85.146) |
| 2024-03-07 20:27:18 +0100 | <haskellbridge> | <eldritchcookie> hourglass has 3500 indirect reverse dependencies and not only is it abandoned it doesn't compile on GHC 9.8 |
| 2024-03-07 20:27:26 +0100 | <haskellbridge> | <eldritchcookie> fun |
| 2024-03-07 20:27:40 +0100 | misterfish | (~misterfis@84.53.85.146) (Ping timeout: 260 seconds) |
| 2024-03-07 20:40:47 +0100 | <tomsmeding> | @hackage acme-everything |
| 2024-03-07 20:40:47 +0100 | <lambdabot> | https://hackage.haskell.org/package/acme-everything |
| 2024-03-07 20:41:03 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2024-03-07 20:48:31 +0100 | <haskellbridge> | <eldritchcookie> is that supposed to be relevant to my message, i don't think i know how? i am just annoyed that i can't compile hoogle because tls doesn't compile due to a transitive dependency on hourglass |
| 2024-03-07 20:49:43 +0100 | komikat_ | (~akshitkr@218.185.248.66) |
| 2024-03-07 20:50:06 +0100 | komikat | (~akshitkr@218.185.248.66) (Read error: Connection reset by peer) |
| 2024-03-07 20:57:56 +0100 | raehik | (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) (Ping timeout: 268 seconds) |
| 2024-03-07 20:59:45 +0100 | jmdaemon | (~jmdaemon@user/jmdaemon) |
| 2024-03-07 21:02:35 +0100 | srz | (~srz@181.228.49.93) |
| 2024-03-07 21:03:52 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2024-03-07 21:04:45 +0100 | <int-e> | worksforme(tm) |
| 2024-03-07 21:05:23 +0100 | dcoutts | (~duncan@cpc69402-oxfd27-2-0-cust903.4-3.cable.virginm.net) (Ping timeout: 264 seconds) |
| 2024-03-07 21:06:10 +0100 | <int-e> | (ignoring the fact that filepath-1.5 breaks stuff and it builds an older version instead) |
| 2024-03-07 21:06:46 +0100 | sord937 | (~sord937@gateway/tor-sasl/sord937) (Quit: sord937) |
| 2024-03-07 21:09:05 +0100 | dsrt^ | (~cd@c-98-242-74-66.hsd1.ga.comcast.net) |
| 2024-03-07 21:16:24 +0100 | wootehfoot | (~wootehfoo@user/wootehfoot) |
| 2024-03-07 21:16:24 +0100 | Guest0 | (~Guest0@129.170.197.184) |
| 2024-03-07 21:17:32 +0100 | raehik | (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) |
| 2024-03-07 21:20:22 +0100 | <Guest0> | I’ve been looking into the trace function for debugging, and I found out that writing some code like this: |
| 2024-03-07 21:20:22 +0100 | <Guest0> | myfun a b | trace ("foo " ++ show a ++ " " ++ show b) debug = a + b |
| 2024-03-07 21:20:23 +0100 | <Guest0> | allows me to print a message whenever some variable called debug is set to True. However, I would like to look into why this works on a conceptual level - if anyone knows the general name for the technique being used to make trace a third parameter of sorts (?), that would be really helpful |
| 2024-03-07 21:21:08 +0100 | <int-e> | that doesn't look right |
| 2024-03-07 21:21:45 +0100 | <int-e> | the way it's written, the message will be printed, the guard will evaluate to false and the rhs a + b won't be used. |
| 2024-03-07 21:21:54 +0100 | ft | (~ft@p508db2e6.dip0.t-ipconnect.de) |
| 2024-03-07 21:21:55 +0100 | <int-e> | if debug = False |
| 2024-03-07 21:22:12 +0100 | <Guest0> | It's set to true |
| 2024-03-07 21:22:38 +0100 | <int-e> | well, trace ... True will print ... and then evaluate to True. |
| 2024-03-07 21:22:57 +0100 | <int-e> | > let x | True = 1 in x |
| 2024-03-07 21:22:58 +0100 | <lambdabot> | 1 |
| 2024-03-07 21:23:24 +0100 | <int-e> | so it's like that but with a side effect. |
| 2024-03-07 21:24:00 +0100 | jmdaemon | (~jmdaemon@user/jmdaemon) (Ping timeout: 255 seconds) |
| 2024-03-07 21:25:56 +0100 | <Guest0> | I see. So the idea is that if you're pattern matching on a function and the part after the guard evaluates to False, the match for that particular pattern fails |
| 2024-03-07 21:26:23 +0100 | srz | (~srz@181.228.49.93) (Ping timeout: 264 seconds) |
| 2024-03-07 21:26:40 +0100 | <geekosaur> | it's not the part after the guard, it's the guard itself |
| 2024-03-07 21:27:11 +0100 | <int-e> | my preferred style of doing this is https://paste.tomsmeding.com/GR8qsVSH -- that way the debug code is easy to comment out |
| 2024-03-07 21:27:11 +0100 | <Guest0> | Right |
| 2024-03-07 21:27:11 +0100 | <geekosaur> | and `Debug.Trace.trace msg a` evaluates to `a`, with a side effect of printing `msg` |
| 2024-03-07 21:27:41 +0100 | <geekosaur> | so a quick hack to trace evaluation of functions is to prefix a failing guard with a trace attached |
| 2024-03-07 21:28:01 +0100 | <geekosaur> | since the guard fails, evaluation falls through to the actual function |
| 2024-03-07 21:28:33 +0100 | <int-e> | (and using tuples and traceShow saves a bunch of `++` and `show` at the expense of a tiny bit of readability) |
| 2024-03-07 21:28:45 +0100 | <tomsmeding> | eldritchcookie: oh sorry I was missing the context that this is actually something you're running into |
| 2024-03-07 21:29:11 +0100 | <tomsmeding> | I thought I was replying to a joke with a joke |
| 2024-03-07 21:30:32 +0100 | <Guest0> | Yeah that definitely looks a lot more clear/readable, thanks for the example |
| 2024-03-07 21:30:54 +0100 | raehik | (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) (Ping timeout: 256 seconds) |
| 2024-03-07 21:31:40 +0100 | Guest0 | (~Guest0@129.170.197.184) (Quit: Client closed) |
| 2024-03-07 21:35:31 +0100 | rncwnd | (~quassel@2a01:4f8:221:27c6::1) (Ping timeout: 256 seconds) |
| 2024-03-07 21:49:14 +0100 | chiselfuse | (~chiselfus@user/chiselfuse) (Ping timeout: 260 seconds) |
| 2024-03-07 21:50:29 +0100 | fmd | (~fmd@user/framend) (Ping timeout: 240 seconds) |
| 2024-03-07 21:51:18 +0100 | chiselfuse | (~chiselfus@user/chiselfuse) |
| 2024-03-07 21:52:00 +0100 | rncwnd | (~quassel@2a01:4f8:221:27c6::1) |
| 2024-03-07 22:01:14 +0100 | chiselfuse | (~chiselfus@user/chiselfuse) (Remote host closed the connection) |
| 2024-03-07 22:01:29 +0100 | zetef | (~quassel@95.77.17.251) |
| 2024-03-07 22:02:10 +0100 | chiselfuse | (~chiselfus@user/chiselfuse) |
| 2024-03-07 22:04:10 +0100 | L29Ah | (~L29Ah@wikipedia/L29Ah) () |
| 2024-03-07 22:06:54 +0100 | _ht | (~Thunderbi@28-52-174-82.ftth.glasoperator.nl) (Remote host closed the connection) |
| 2024-03-07 22:08:10 +0100 | zetef_ | (~quassel@5.2.182.98) |
| 2024-03-07 22:08:13 +0100 | zetef | (~quassel@95.77.17.251) (Ping timeout: 264 seconds) |
| 2024-03-07 22:08:52 +0100 | alexherbo2 | (~alexherbo@2a02-8440-3240-c50e-314b-952c-1197-8413.rev.sfr.net) |
| 2024-03-07 22:18:48 +0100 | tri | (~tri@ool-18bbef1a.static.optonline.net) |
| 2024-03-07 22:23:51 +0100 | tri | (~tri@ool-18bbef1a.static.optonline.net) (Ping timeout: 272 seconds) |
| 2024-03-07 22:27:02 +0100 | alexherbo2 | (~alexherbo@2a02-8440-3240-c50e-314b-952c-1197-8413.rev.sfr.net) (Remote host closed the connection) |
| 2024-03-07 22:31:49 +0100 | jau_ | (~user@134.101.168.5.dynamic-pppoe.dt.ipv4.wtnet.de) (Quit: Leaving) |
| 2024-03-07 22:32:03 +0100 | ski | (~ski@ext-1-033.eduroam.chalmers.se) (Ping timeout: 260 seconds) |
| 2024-03-07 22:33:25 +0100 | ski | (~ski@ext-1-033.eduroam.chalmers.se) |
| 2024-03-07 22:36:08 +0100 | wootehfoot | (~wootehfoo@user/wootehfoot) (Read error: Connection reset by peer) |
| 2024-03-07 22:38:43 +0100 | rncwnd | (~quassel@2a01:4f8:221:27c6::1) (Ping timeout: 255 seconds) |
| 2024-03-07 22:39:00 +0100 | mark` | (~user@user/mark/x-6044658) |
| 2024-03-07 22:39:26 +0100 | mark` | (~user@user/mark/x-6044658) (Quit: ERC 5.5.0.29.1 (IRC client for GNU Emacs 29.1)) |
| 2024-03-07 22:41:00 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2024-03-07 22:42:01 +0100 | target_i | (~target_i@user/target-i/x-6023099) (Quit: leaving) |
| 2024-03-07 22:47:41 +0100 | dcoutts | (~duncan@cpc69402-oxfd27-2-0-cust903.4-3.cable.virginm.net) |
| 2024-03-07 22:48:12 +0100 | machinedgod | (~machinedg@d173-183-246-216.abhsia.telus.net) |
| 2024-03-07 22:51:06 +0100 | michalz | (~michalz@185.246.207.200) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2024-03-07 22:54:43 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2024-03-07 22:57:55 +0100 | rncwnd | (~quassel@2a01:4f8:221:27c6::1) |
| 2024-03-07 23:01:36 +0100 | noumenon | (~noumenon@113.51-175-156.customer.lyse.net) |
| 2024-03-07 23:02:03 +0100 | L29Ah | (~L29Ah@wikipedia/L29Ah) |
| 2024-03-07 23:03:24 +0100 | pavonia | (~user@user/siracusa) |
| 2024-03-07 23:04:21 +0100 | jargon | (~jargon@154.sub-174-205-226.myvzw.com) |
| 2024-03-07 23:05:18 +0100 | ChaiTRex | (~ChaiTRex@user/chaitrex) (Ping timeout: 260 seconds) |
| 2024-03-07 23:06:16 +0100 | Katarushisu1 | (~Katarushi@finc-20-b2-v4wan-169598-cust1799.vm7.cable.virginm.net) (Quit: Ping timeout (120 seconds)) |
| 2024-03-07 23:06:58 +0100 | phma | (phma@2001:5b0:211f:bff8:ed6a:61e2:ef0c:3875) (Read error: Connection reset by peer) |
| 2024-03-07 23:08:05 +0100 | phma | (phma@2001:5b0:2172:bea8:4de3:ce84:5b1f:c1a2) |
| 2024-03-07 23:08:52 +0100 | Katarushisu1 | (~Katarushi@finc-20-b2-v4wan-169598-cust1799.vm7.cable.virginm.net) |
| 2024-03-07 23:15:23 +0100 | euphores | (~SASL_euph@user/euphores) (Quit: Leaving.) |
| 2024-03-07 23:15:36 +0100 | ChaiTRex | (~ChaiTRex@user/chaitrex) |
| 2024-03-07 23:16:03 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2024-03-07 23:19:12 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2024-03-07 23:20:57 +0100 | srz | (~srz@181.228.49.93) |
| 2024-03-07 23:23:02 +0100 | ChaiTRex | (~ChaiTRex@user/chaitrex) (Ping timeout: 260 seconds) |
| 2024-03-07 23:25:01 +0100 | euphores | (~SASL_euph@user/euphores) |
| 2024-03-07 23:25:45 +0100 | zetef_ | (~quassel@5.2.182.98) (Remote host closed the connection) |
| 2024-03-07 23:25:46 +0100 | ChaiTRex | (~ChaiTRex@user/chaitrex) |
| 2024-03-07 23:29:24 +0100 | Square3 | (~Square4@user/square) |
| 2024-03-07 23:31:18 +0100 | ChaiTRex | (~ChaiTRex@user/chaitrex) (Remote host closed the connection) |
| 2024-03-07 23:31:53 +0100 | ChaiTRex | (~ChaiTRex@user/chaitrex) |
| 2024-03-07 23:32:16 +0100 | Square | (~Square@user/square) (Ping timeout: 255 seconds) |
| 2024-03-07 23:32:49 +0100 | tri | (~tri@ool-18bbef1a.static.optonline.net) |
| 2024-03-07 23:33:25 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2024-03-07 23:37:10 +0100 | tri | (~tri@ool-18bbef1a.static.optonline.net) (Ping timeout: 264 seconds) |
| 2024-03-07 23:43:02 +0100 | fmd | (~fmd@2a02-8429-4b52-f901-ef8a-cb4a-81a3-e1f5.rev.sfr.net) |
| 2024-03-07 23:45:25 +0100 | takuan | (~takuan@178-116-218-225.access.telenet.be) (Remote host closed the connection) |
| 2024-03-07 23:49:13 +0100 | Sgeo | (~Sgeo@user/sgeo) |