| 2024-12-19 00:06:46 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-12-19 00:08:55 +0100 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) peterbecich |
| 2024-12-19 00:11:13 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 248 seconds) |
| 2024-12-19 00:13:57 +0100 | LainExperiments | (~LainExper@user/LainExperiments) LainExperiments |
| 2024-12-19 00:14:23 +0100 | LainExperiments | (~LainExper@user/LainExperiments) (Client Quit) |
| 2024-12-19 00:14:25 +0100 | LainExperiments4 | (~LainExper@user/LainExperiments) LainExperiments |
| 2024-12-19 00:16:15 +0100 | Tuplanolla | (~Tuplanoll@91-159-69-59.elisa-laajakaista.fi) Tuplanolla |
| 2024-12-19 00:22:09 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-12-19 00:26:34 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 244 seconds) |
| 2024-12-19 00:36:24 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2024-12-19 00:37:42 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-12-19 00:42:40 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 260 seconds) |
| 2024-12-19 00:43:15 +0100 | cheater | (~Username@user/cheater) (Quit: Going offline, see ya! (www.adiirc.com)) |
| 2024-12-19 00:44:21 +0100 | dsrt^ | (dsrt@c-98-242-74-66.hsd1.ga.comcast.net) (Ping timeout: 265 seconds) |
| 2024-12-19 00:53:05 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-12-19 00:53:57 +0100 | __monty__ | (~toonn@user/toonn) (Quit: leaving) |
| 2024-12-19 00:57:29 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2024-12-19 00:57:48 +0100 | gmg | (~user@user/gehmehgeh) (Ping timeout: 264 seconds) |
| 2024-12-19 01:02:34 +0100 | ByronJohnson | (~bairyn@50.250.232.19) (Ping timeout: 252 seconds) |
| 2024-12-19 01:03:07 +0100 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 264 seconds) |
| 2024-12-19 01:04:05 +0100 | ByronJohnson | (~bairyn@50.250.232.19) ByronJohnson |
| 2024-12-19 01:08:29 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-12-19 01:09:29 +0100 | notzmv | (~umar@user/notzmv) (Ping timeout: 265 seconds) |
| 2024-12-19 01:10:36 +0100 | lol_ | (~lol@2603:3016:1e01:b9c0:e49a:26f1:1256:b271) |
| 2024-12-19 01:10:51 +0100 | dsrt^ | (~dsrt@c-98-242-74-66.hsd1.ga.comcast.net) |
| 2024-12-19 01:12:46 +0100 | ystael | (~ystael@user/ystael) ystael |
| 2024-12-19 01:13:39 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 276 seconds) |
| 2024-12-19 01:14:34 +0100 | jcarpenter2 | (~lol@2603:3016:1e01:b9c0:5004:d446:5b51:cb8b) (Ping timeout: 260 seconds) |
| 2024-12-19 01:23:51 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-12-19 01:30:45 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 265 seconds) |
| 2024-12-19 01:34:08 +0100 | jle` | (~jle`@syn-023-240-075-236.res.spectrum.com) (Ping timeout: 265 seconds) |
| 2024-12-19 01:35:53 +0100 | jle` | (~jle`@2603:8001:3b02:84d4::1000) jle` |
| 2024-12-19 01:37:03 +0100 | dsrt^ | (~dsrt@c-98-242-74-66.hsd1.ga.comcast.net) (Ping timeout: 276 seconds) |
| 2024-12-19 01:44:45 +0100 | dsrt^ | (~dsrt@c-98-242-74-66.hsd1.ga.comcast.net) |
| 2024-12-19 01:45:44 +0100 | dostoevsky_ | (~dostoevsk@user/dostoevsky) (Quit: Leaving) |
| 2024-12-19 01:46:03 +0100 | LainExperiments4 | (~LainExper@user/LainExperiments) (Quit: Client closed) |
| 2024-12-19 01:46:38 +0100 | dostoevsky | (~dostoevsk@user/dostoevsky) dostoevsky |
| 2024-12-19 01:47:38 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-12-19 01:50:34 +0100 | sawilagar | (~sawilagar@user/sawilagar) (Ping timeout: 265 seconds) |
| 2024-12-19 01:52:30 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 265 seconds) |
| 2024-12-19 01:54:04 +0100 | Unicorn_Princess | (~Unicorn_P@user/Unicorn-Princess/x-3540542) (Remote host closed the connection) |
| 2024-12-19 01:54:11 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-12-19 01:56:30 +0100 | sprotte24 | (~sprotte24@p200300d16f0dce00c42912c31568f36e.dip0.t-ipconnect.de) (Quit: Leaving) |
| 2024-12-19 01:58:47 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 265 seconds) |
| 2024-12-19 02:00:31 +0100 | fmira | (~user@user/fmira) (Remote host closed the connection) |
| 2024-12-19 02:01:23 +0100 | fmira | (~user@user/fmira) fmira |
| 2024-12-19 02:02:10 +0100 | fmira | (~user@user/fmira) (Remote host closed the connection) |
| 2024-12-19 02:04:49 +0100 | acidjnk_new | (~acidjnk@p200300d6e7283f667119c200ba695214.dip0.t-ipconnect.de) (Ping timeout: 248 seconds) |
| 2024-12-19 02:09:27 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-12-19 02:13:46 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2024-12-19 02:17:21 +0100 | xff0x | (~xff0x@2405:6580:b080:900:c5e5:bb72:26a4:9b68) (Ping timeout: 244 seconds) |
| 2024-12-19 02:23:02 +0100 | LainExperiments | (~LainExper@user/LainExperiments) LainExperiments |
| 2024-12-19 02:24:50 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-12-19 02:29:43 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 265 seconds) |
| 2024-12-19 02:30:40 +0100 | ph88 | (~ph88@2a02:8109:9e26:c800:851e:84df:7cc0:34b6) (Remote host closed the connection) |
| 2024-12-19 02:32:49 +0100 | machinedgod | (~machinedg@d108-173-18-100.abhsia.telus.net) (Ping timeout: 252 seconds) |
| 2024-12-19 02:36:34 +0100 | alp | (~alp@2001:861:8ca0:4940:268e:5456:127:feca) (Ping timeout: 272 seconds) |
| 2024-12-19 02:39:53 +0100 | Tuplanolla | (~Tuplanoll@91-159-69-59.elisa-laajakaista.fi) (Quit: Leaving.) |
| 2024-12-19 02:40:14 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-12-19 02:40:56 +0100 | weary-traveler | (~user@user/user363627) (Remote host closed the connection) |
| 2024-12-19 02:44:52 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2024-12-19 02:53:41 +0100 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) peterbecich |
| 2024-12-19 02:55:37 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-12-19 02:59:57 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2024-12-19 03:02:40 +0100 | Igloo | (~ian@81.2.99.210) (Quit: BIAB) |
| 2024-12-19 03:09:10 +0100 | xff0x | (~xff0x@182.169.73.28) |
| 2024-12-19 03:10:59 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-12-19 03:13:04 +0100 | Igloo | (~ian@81.2.99.210) Igfoo |
| 2024-12-19 03:15:38 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 265 seconds) |
| 2024-12-19 03:15:50 +0100 | mzg | (mzg@abusers.hu) (Ping timeout: 272 seconds) |
| 2024-12-19 03:17:14 +0100 | notzmv | (~umar@user/notzmv) notzmv |
| 2024-12-19 03:18:08 +0100 | Smiles | (uid551636@id-551636.lymington.irccloud.com) Smiles |
| 2024-12-19 03:26:21 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-12-19 03:31:27 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 276 seconds) |
| 2024-12-19 03:41:15 +0100 | dsrt^ | (~dsrt@c-98-242-74-66.hsd1.ga.comcast.net) (Ping timeout: 265 seconds) |
| 2024-12-19 03:41:44 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-12-19 03:46:31 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 244 seconds) |
| 2024-12-19 03:48:19 +0100 | dsrt^ | (dsrt@c-98-242-74-66.hsd1.ga.comcast.net) |
| 2024-12-19 03:53:20 +0100 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 265 seconds) |
| 2024-12-19 03:57:30 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-12-19 04:02:10 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 260 seconds) |
| 2024-12-19 04:10:39 +0100 | lol_ | jcarpenter2 |
| 2024-12-19 04:12:53 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-12-19 04:17:31 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 244 seconds) |
| 2024-12-19 04:28:16 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-12-19 04:32:58 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 265 seconds) |
| 2024-12-19 04:43:40 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-12-19 04:46:59 +0100 | td_ | (~td@i53870921.versanet.de) (Ping timeout: 265 seconds) |
| 2024-12-19 04:48:31 +0100 | td_ | (~td@i53870932.versanet.de) td_ |
| 2024-12-19 04:50:09 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 248 seconds) |
| 2024-12-19 05:01:00 +0100 | ljdarj | (~Thunderbi@user/ljdarj) (Ping timeout: 265 seconds) |
| 2024-12-19 05:01:43 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-12-19 05:02:21 +0100 | LainExperiments | (~LainExper@user/LainExperiments) (Quit: Client closed) |
| 2024-12-19 05:06:43 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 264 seconds) |
| 2024-12-19 05:11:43 +0100 | OftenFaded | (~OftenFade@user/tisktisk) OftenFaded |
| 2024-12-19 05:17:05 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-12-19 05:21:57 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 276 seconds) |
| 2024-12-19 05:26:55 +0100 | Smiles | (uid551636@id-551636.lymington.irccloud.com) (Quit: Connection closed for inactivity) |
| 2024-12-19 05:27:39 +0100 | rekahsoft | (~rekahsoft@76.69.85.220) rekahsoft |
| 2024-12-19 05:31:10 +0100 | aforemny | (~aforemny@2001:9e8:6cf7:7000:54e5:6684:9196:e657) aforemny |
| 2024-12-19 05:31:49 +0100 | aforemny_ | (~aforemny@2001:9e8:6cd7:5a00:85fb:8e26:5d91:c068) (Ping timeout: 248 seconds) |
| 2024-12-19 05:32:28 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-12-19 05:35:38 +0100 | rekahsoft | (~rekahsoft@76.69.85.220) (Remote host closed the connection) |
| 2024-12-19 05:37:15 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 265 seconds) |
| 2024-12-19 05:37:40 +0100 | Axman6 | (~Axman6@user/axman6) (Ping timeout: 240 seconds) |
| 2024-12-19 05:37:48 +0100 | rekahsoft | (~rekahsoft@76.69.85.220) rekahsoft |
| 2024-12-19 05:47:51 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-12-19 05:51:58 +0100 | pavonia | (~user@user/siracusa) (Quit: Bye!) |
| 2024-12-19 05:52:18 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2024-12-19 05:52:22 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) bitdex |
| 2024-12-19 05:57:18 +0100 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) peterbecich |
| 2024-12-19 05:59:52 +0100 | lucabtz | (~lucabtz@user/lucabtz) lucabtz |
| 2024-12-19 06:00:40 +0100 | tnt1 | (~Thunderbi@user/tnt1) tnt1 |
| 2024-12-19 06:03:14 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-12-19 06:03:48 +0100 | rekahsoft | (~rekahsoft@76.69.85.220) (Remote host closed the connection) |
| 2024-12-19 06:07:31 +0100 | rekahsoft | (~rekahsoft@76.69.85.220) rekahsoft |
| 2024-12-19 06:08:11 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 265 seconds) |
| 2024-12-19 06:09:58 +0100 | rekahsoft | (~rekahsoft@76.69.85.220) (Remote host closed the connection) |
| 2024-12-19 06:18:37 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-12-19 06:23:20 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 260 seconds) |
| 2024-12-19 06:35:15 +0100 | Square | (~Square4@user/square) (Ping timeout: 265 seconds) |
| 2024-12-19 06:39:51 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-12-19 06:49:42 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 276 seconds) |
| 2024-12-19 06:54:04 +0100 | housemate | (~housemate@246.224.218.139.sta.wbroadband.net.au) housemate |
| 2024-12-19 06:55:31 +0100 | housemate | (~housemate@246.224.218.139.sta.wbroadband.net.au) (Remote host closed the connection) |
| 2024-12-19 06:59:18 +0100 | gmg | (~user@user/gehmehgeh) gehmehgeh |
| 2024-12-19 06:59:53 +0100 | gorignak | (~gorignak@user/gorignak) gorignak |
| 2024-12-19 07:00:27 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-12-19 07:04:58 +0100 | vanishingideal | (~vanishing@user/vanishingideal) vanishingideal |
| 2024-12-19 07:05:13 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 265 seconds) |
| 2024-12-19 07:06:33 +0100 | mari-estel | (~mari-este@user/mari-estel) mari-estel |
| 2024-12-19 07:07:13 +0100 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 252 seconds) |
| 2024-12-19 07:15:49 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-12-19 07:17:46 +0100 | alp | (~alp@2001:861:8ca0:4940:c0a6:33b6:1011:7f5b) |
| 2024-12-19 07:19:36 +0100 | michalz | (~michalz@185.246.207.217) |
| 2024-12-19 07:20:25 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2024-12-19 07:21:12 +0100 | ChaiTRex | (~ChaiTRex@user/chaitrex) (Ping timeout: 264 seconds) |
| 2024-12-19 07:21:40 +0100 | ChaiTRex | (~ChaiTRex@user/chaitrex) ChaiTRex |
| 2024-12-19 07:22:12 +0100 | ephilalethes | (~noumenon@202.186.203.84) (Ping timeout: 276 seconds) |
| 2024-12-19 07:25:13 +0100 | mari99981 | (~mari-este@user/mari-estel) mari-estel |
| 2024-12-19 07:25:13 +0100 | mari99981 | (~mari-este@user/mari-estel) (Client Quit) |
| 2024-12-19 07:26:56 +0100 | takuan | (~takuan@178-116-218-225.access.telenet.be) |
| 2024-12-19 07:27:08 +0100 | mari-estel | (~mari-este@user/mari-estel) (Ping timeout: 244 seconds) |
| 2024-12-19 07:31:10 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-12-19 07:37:54 +0100 | swamp_ | (~zmt00@user/zmt00) (Read error: Connection reset by peer) |
| 2024-12-19 07:38:00 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 260 seconds) |
| 2024-12-19 07:38:19 +0100 | swamp_ | (~zmt00@user/zmt00) zmt00 |
| 2024-12-19 07:49:12 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-12-19 07:53:37 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 248 seconds) |
| 2024-12-19 08:00:07 +0100 | dostoevsky | (~dostoevsk@user/dostoevsky) (Remote host closed the connection) |
| 2024-12-19 08:00:50 +0100 | dostoevsky | (~dostoevsk@user/dostoevsky) dostoevsky |
| 2024-12-19 08:04:36 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-12-19 08:08:59 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 244 seconds) |
| 2024-12-19 08:11:16 +0100 | rvalue | (~rvalue@user/rvalue) (Ping timeout: 252 seconds) |
| 2024-12-19 08:13:10 +0100 | CiaoSen | (~Jura@2a05:5800:2d8:3500:ca4b:d6ff:fec1:99da) CiaoSen |
| 2024-12-19 08:19:59 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-12-19 08:24:37 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 248 seconds) |
| 2024-12-19 08:51:45 +0100 | <eugenrh> | L29Ah: instead of vim+HLS I plan on using vim+ghci.. I wrote about it here: https://discourse.haskell.org/t/ghci-can-send-data-to-vim-via-terminal-and-vice-versa/9281 |
| 2024-12-19 08:52:14 +0100 | <eugenrh> | In a few months I think I'll have time to implement/play with that |
| 2024-12-19 08:53:34 +0100 | <eugenrh> | HLS is a monster.. Last time I've installed it with ghcup, it was 2.9GB large. That's crazy. I don't want to depend on such bloat. |
| 2024-12-19 08:56:43 +0100 | alp | (~alp@2001:861:8ca0:4940:c0a6:33b6:1011:7f5b) (Ping timeout: 252 seconds) |
| 2024-12-19 08:57:05 +0100 | <c_wraith> | I've spent too long looking at AoC solutions. I'm having to resist writing stuff like `(,) <*> foo <$> bar' just to avoid a list comprehension |
| 2024-12-19 08:57:40 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2024-12-19 08:58:52 +0100 | Axman6 | (~Axman6@user/axman6) Axman6 |
| 2024-12-19 09:00:01 +0100 | caconym | (~caconym@user/caconym) (Quit: bye) |
| 2024-12-19 09:00:38 +0100 | caconym | (~caconym@user/caconym) caconym |
| 2024-12-19 09:04:21 +0100 | michalz | (~michalz@185.246.207.217) (Ping timeout: 252 seconds) |
| 2024-12-19 09:06:46 +0100 | michalz | (~michalz@185.246.207.201) |
| 2024-12-19 09:07:28 +0100 | lortabac | (~lortabac@2a01:e0a:541:b8f0:55ab:e185:7f81:54a4) lortabac |
| 2024-12-19 09:11:07 +0100 | <kqr> | Is there a way to find out if an export from a library is not used in a project? The underlying problem is that I have several definitions in a legacy project that are not used and will not be used, and I'd like to clean them up. My current process is to stumble over a candidate, try deleting it, and if everything still compiles it wasn't used. But I'd love something more systematic! |
| 2024-12-19 09:11:41 +0100 | michalz_ | (~michalz@185.246.207.221) |
| 2024-12-19 09:11:51 +0100 | michalz | (~michalz@185.246.207.201) (Ping timeout: 265 seconds) |
| 2024-12-19 09:12:20 +0100 | dsrt^ | (dsrt@c-98-242-74-66.hsd1.ga.comcast.net) (Ping timeout: 265 seconds) |
| 2024-12-19 09:16:40 +0100 | mzg | (mzg@abusers.hu) |
| 2024-12-19 09:18:23 +0100 | vpan | (~vpan@212.117.1.172) |
| 2024-12-19 09:19:20 +0100 | michalz_ | (~michalz@185.246.207.221) (Quit: ZNC 1.9.0 - https://znc.in) |
| 2024-12-19 09:19:50 +0100 | michalz | (~michalz@185.246.207.193) |
| 2024-12-19 09:23:32 +0100 | Axma98477 | (~Axman6@user/axman6) Axman6 |
| 2024-12-19 09:24:27 +0100 | <probie> | kqr: In the event you don't find a proper solution, you could probably speed that loop up by exporting nothing at all, and then adding back in only the ones which the compiler says are missing |
| 2024-12-19 09:25:41 +0100 | Axman6 | (~Axman6@user/axman6) (Ping timeout: 250 seconds) |
| 2024-12-19 09:30:08 +0100 | briandaed | (~root@user/briandaed) briandaed |
| 2024-12-19 09:49:07 +0100 | dsrt^ | (~dsrt@c-98-242-74-66.hsd1.ga.comcast.net) |
| 2024-12-19 09:49:37 +0100 | lxsameer | (~lxsameer@Serene/lxsameer) lxsameer |
| 2024-12-19 09:58:07 +0100 | machinedgod | (~machinedg@d108-173-18-100.abhsia.telus.net) machinedgod |
| 2024-12-19 09:59:19 +0100 | acidjnk_new | (~acidjnk@p200300d6e7283f997119c200ba695214.dip0.t-ipconnect.de) acidjnk |
| 2024-12-19 10:00:16 +0100 | youthlic | (~Thunderbi@user/youthlic) (Quit: youthlic) |
| 2024-12-19 10:01:52 +0100 | tzh | (~tzh@c-76-115-131-146.hsd1.or.comcast.net) (Quit: zzz) |
| 2024-12-19 10:02:04 +0100 | Sgeo | (~Sgeo@user/sgeo) (Read error: Connection reset by peer) |
| 2024-12-19 10:02:09 +0100 | youthlic | (~Thunderbi@user/youthlic) youthlic |
| 2024-12-19 10:04:32 +0100 | merijn | (~merijn@77.242.116.146) merijn |
| 2024-12-19 10:05:39 +0100 | mari-estel | (~mari-este@user/mari-estel) mari-estel |
| 2024-12-19 10:07:31 +0100 | <vpan> | hi, I need to run a number of `IO (Maybe a)` actions and it would be nice to return an `Either String a` with message on which stage failed, if any. I saw somewhere in the documentation (can't find the reference right now) that you can just execute a sequence of `IO (Either a b)` actions in a do block and either the last result or the first failure will be returned without the need for nested `case` blocks. |
| 2024-12-19 10:07:32 +0100 | <vpan> | But I get an error when trying to get the result out of an `Either` using `<-`, see https://paste.tomsmeding.com/8ZZmsTyP . Should I be looking at `ExceptT` or is there a simpler approach? |
| 2024-12-19 10:10:29 +0100 | <kaol> | maybeToEither doesn't return an IO anything. You need to use a let to define episode, not a bind. |
| 2024-12-19 10:13:35 +0100 | <vpan> | but then I'm back to checking the case of `Either` "manually" resulting in nested blocks I would like to avoid. `Either` has a `Monad` instance, so bind should be usable, I suppose just not compatible with the current function signature? |
| 2024-12-19 10:13:50 +0100 | <Leary> | :t runExceptT . traverse ExceptT . zipWith (\i -> fmap (maybe (Left i) Right)) [0..] |
| 2024-12-19 10:13:51 +0100 | <lambdabot> | (Monad m, Num e, Enum e) => [m (Maybe b)] -> m (Either e [b]) |
| 2024-12-19 10:13:58 +0100 | <Leary> | Not sure if helpful. |
| 2024-12-19 10:14:15 +0100 | <kaol> | I think ExceptT is the simpler approach. Make sure the e types in every Either e align and then it's a matter of labeling everything with ExceptT and using runExceptT on the whole. |
| 2024-12-19 10:14:38 +0100 | <kaol> | If it's some pure IO with no Either, use lift. If it's a different e transform it with withExceptT. |
| 2024-12-19 10:16:33 +0100 | <kaol> | If you make your functions use ExceptT on their end then you'd save the labeling with ExceptT part from the place where you use them. |
| 2024-12-19 10:17:34 +0100 | <vpan> | ok, thanks! As a beginner I often find myself missing the obvious simple solutions, so wanted to check if `ExceptT` is not an overkill in this case. :) |
| 2024-12-19 10:18:19 +0100 | mari16773 | (~mari-este@user/mari-estel) mari-estel |
| 2024-12-19 10:18:19 +0100 | <kaol> | I think it's fine. Give it a try, if it fits (and sounds like it would) it's great. |
| 2024-12-19 10:19:51 +0100 | <kqr> | probie, that is a clever idea! Thanks |
| 2024-12-19 10:20:17 +0100 | mari-estel | (~mari-este@user/mari-estel) (Ping timeout: 248 seconds) |
| 2024-12-19 10:23:56 +0100 | <Leary> | vpan: If you're already in `IO`, it's usually better to use `IO`s exception mechanism than to use `Maybe` or `Either` or put `ExceptT` over it. |
| 2024-12-19 10:25:58 +0100 | mari-estel | (~mari-este@user/mari-estel) mari-estel |
| 2024-12-19 10:28:20 +0100 | mari16773 | (~mari-este@user/mari-estel) (Ping timeout: 260 seconds) |
| 2024-12-19 10:30:11 +0100 | <vpan> | Leary: right, I may be trying too hard to avoid the nasty exceptions. :) Anyway, my intention in this case was simply to flatten the nested `case` blocks checking for `Just`/`Nothing` (which was my first approach) to make it more readable. Not technically necessary, I'm just trying to explore idiomatic and readable ways to do things. |
| 2024-12-19 10:31:22 +0100 | <kaol> | Some people like to keep their IO code exceptions free. I'd save using them for situations that are, well, exceptional. If it's a section of code where taking the exit rail is an expected outcome I'd prefer the more explicit style of ExceptT. |
| 2024-12-19 10:31:58 +0100 | <Leary> | kqr: I'll be interested to hear about it if you /do/ find a good solution. A not-so-good one would be to manually merge all the modules into `module Main (main) ...` before rebuilding with `-Wunused-top-binds`. |
| 2024-12-19 10:32:52 +0100 | rvalue | (~rvalue@user/rvalue) rvalue |
| 2024-12-19 10:34:01 +0100 | mari-estel | (~mari-este@user/mari-estel) (Ping timeout: 252 seconds) |
| 2024-12-19 10:34:12 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2024-12-19 10:35:11 +0100 | mari-estel | (~mari-este@user/mari-estel) mari-estel |
| 2024-12-19 10:43:59 +0100 | rvalue | (~rvalue@user/rvalue) (Ping timeout: 244 seconds) |
| 2024-12-19 10:45:56 +0100 | rvalue | (~rvalue@user/rvalue) rvalue |
| 2024-12-19 10:47:50 +0100 | ubert | (~Thunderbi@2a02:8109:ab8a:5a00:f6f5:1546:1c7e:72ab) ubert |
| 2024-12-19 10:48:17 +0100 | alexherbo2 | (~alexherbo@2a02-8440-350c-d1b2-f913-af6a-c348-0a7f.rev.sfr.net) alexherbo2 |
| 2024-12-19 10:50:37 +0100 | alp | (~alp@2001:861:8ca0:4940:b388:1d7b:42d:b62) |
| 2024-12-19 10:51:24 +0100 | mari-estel | (~mari-este@user/mari-estel) (Quit: bluetooth) |
| 2024-12-19 10:53:38 +0100 | mari-estel | (~mari-este@user/mari-estel) mari-estel |
| 2024-12-19 10:55:03 +0100 | homo_ | (~homo@82-128-217-24.bb.dnainternet.fi) |
| 2024-12-19 10:55:15 +0100 | tt12310978324354 | (~tt1231@2603:6010:8700:4a81:219f:50d3:618a:a6ee) (Quit: Ping timeout (120 seconds)) |
| 2024-12-19 10:55:31 +0100 | homo_ | (~homo@82-128-217-24.bb.dnainternet.fi) (Changing host) |
| 2024-12-19 10:55:31 +0100 | homo_ | (~homo@user/homo) homo |
| 2024-12-19 10:55:41 +0100 | tt12310978324354 | (~tt1231@2603:6010:8700:4a81:219f:50d3:618a:a6ee) tt1231 |
| 2024-12-19 10:55:55 +0100 | homo | (~homo@user/homo) (Quit: Quit) |
| 2024-12-19 10:55:56 +0100 | homo_ | homo |
| 2024-12-19 10:58:00 +0100 | ridcully | (~ridcully@p57b52f42.dip0.t-ipconnect.de) (Ping timeout: 276 seconds) |
| 2024-12-19 10:58:10 +0100 | michalz | (~michalz@185.246.207.193) (Ping timeout: 272 seconds) |
| 2024-12-19 11:01:23 +0100 | michalz | (~michalz@185.246.207.221) |
| 2024-12-19 11:02:24 +0100 | <vpan> | found an article that demonstrates something similar to what I was trying to do - https://mmhaskell.com/blog/2022/3/3/using-either-as-a-monad |
| 2024-12-19 11:02:25 +0100 | <vpan> | But it does not make sense to me, for example, this piece of code https://paste.tomsmeding.com/bGu9FDh2 : if bind is used for result, it's type should be `User` and yet it is used in a `case`. Not to mention the bind should not work the same way it did not work in my attempt... |
| 2024-12-19 11:02:49 +0100 | ridcully | (~ridcully@p57b52ec2.dip0.t-ipconnect.de) ridcully |
| 2024-12-19 11:07:14 +0100 | michalz | (~michalz@185.246.207.221) (Ping timeout: 244 seconds) |
| 2024-12-19 11:08:12 +0100 | <geekosaur> | are you sure you understand it? it looks sensible to me |
| 2024-12-19 11:08:26 +0100 | <geekosaur> | hm, wait, no |
| 2024-12-19 11:08:42 +0100 | <geekosaur> | oh, it's in IO. yes, it's valid |
| 2024-12-19 11:12:34 +0100 | housemate | (~housemate@246.224.218.139.sta.wbroadband.net.au) housemate |
| 2024-12-19 11:13:49 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2024-12-19 11:14:30 +0100 | homo | (~homo@user/homo) (Quit: homo) |
| 2024-12-19 11:14:45 +0100 | homo | (~homo@user/homo) homo |
| 2024-12-19 11:17:13 +0100 | lortabac | (~lortabac@2a01:e0a:541:b8f0:55ab:e185:7f81:54a4) (Quit: WeeChat 4.4.2) |
| 2024-12-19 11:17:20 +0100 | michalz | (~michalz@185.246.207.218) |
| 2024-12-19 11:25:52 +0100 | michalz | (~michalz@185.246.207.218) (Quit: ZNC 1.9.0 - https://znc.in) |
| 2024-12-19 11:26:55 +0100 | michalz | (~michalz@185.246.207.217) |
| 2024-12-19 11:29:53 +0100 | Pixi` | (~Pixi@user/pixi) Pixi |
| 2024-12-19 11:30:13 +0100 | <absence> | If I have a list of values of a sum type, and combine the values element-wise, the result would be a product of combined elements. Similarly, if I wanted to filter such a list of sums, I'd need a product of predicates. There seems to be a relationship/duality between the sum and products, does this have a name I can look up to learn more? |
| 2024-12-19 11:31:22 +0100 | __monty__ | (~toonn@user/toonn) toonn |
| 2024-12-19 11:31:58 +0100 | Pixi__ | (~Pixi@user/pixi) Pixi |
| 2024-12-19 11:32:02 +0100 | Pixi | (~Pixi@user/pixi) (Ping timeout: 244 seconds) |
| 2024-12-19 11:32:33 +0100 | Smiles | (uid551636@id-551636.lymington.irccloud.com) Smiles |
| 2024-12-19 11:35:24 +0100 | Pixi` | (~Pixi@user/pixi) (Ping timeout: 265 seconds) |
| 2024-12-19 11:42:40 +0100 | mreh | (~matthew@host86-146-25-68.range86-146.btcentralplus.com) mreh |
| 2024-12-19 11:43:52 +0100 | <mreh> | I'm confused about wether I should be using Managed, ContT or Codensity. |
| 2024-12-19 11:44:16 +0100 | JuanDaugherty | (~juan@user/JuanDaugherty) JuanDaugherty |
| 2024-12-19 11:44:19 +0100 | <mreh> | I think Managed is out because I'd like a transformer |
| 2024-12-19 11:44:31 +0100 | <opqdonut> | absence: it sounds like your sum type is not really (Either a b) but more like ([a],[b]) |
| 2024-12-19 11:44:42 +0100 | <opqdonut> | absence: and then you have something like the product of free monoids |
| 2024-12-19 11:44:46 +0100 | <mreh> | Codensity is Cont but without callCC? |
| 2024-12-19 11:44:55 +0100 | <mreh> | ContT* |
| 2024-12-19 11:45:17 +0100 | <opqdonut> | absence: with generators of shapes ([a],[]) and ([],[b]) |
| 2024-12-19 11:45:23 +0100 | <mari-estel> | huh can this problem be solved without stacks? |
| 2024-12-19 11:45:33 +0100 | <mari-estel> | %t Managed |
| 2024-12-19 11:45:50 +0100 | <mari-estel> | %:t Managed |
| 2024-12-19 11:46:02 +0100 | <mari-estel> | i think i forgot that syntax again... |
| 2024-12-19 11:46:13 +0100 | <mari-estel> | > :t Managed |
| 2024-12-19 11:46:14 +0100 | <lambdabot> | <hint>:1:1: error: parse error on input ‘:’ |
| 2024-12-19 11:46:22 +0100 | <mari-estel> | >:t Managed |
| 2024-12-19 11:46:43 +0100 | <mari-estel> | whatever |
| 2024-12-19 11:46:55 +0100 | <mreh> | mari-estel: I'm allocating a bunch of Vulkan, and I could remember to clean up after myself, but where's the fun in that. |
| 2024-12-19 11:46:56 +0100 | <probie> | :t Managed |
| 2024-12-19 11:46:57 +0100 | <lambdabot> | error: Data constructor not in scope: Managed |
| 2024-12-19 11:47:08 +0100 | <mreh> | Vulkan objects |
| 2024-12-19 11:47:29 +0100 | <mari-estel> | huh vulkan ... what's that again... |
| 2024-12-19 11:47:34 +0100 | <mari-estel> | @hoogle vulkan |
| 2024-12-19 11:47:34 +0100 | <lambdabot> | package vulkan |
| 2024-12-19 11:47:34 +0100 | <lambdabot> | module SDL.Video.Vulkan |
| 2024-12-19 11:47:34 +0100 | <lambdabot> | package Vulkan |
| 2024-12-19 11:47:37 +0100 | <mari-estel> | i see |
| 2024-12-19 11:47:51 +0100 | <probie> | the modern thing that is "better than OpenGL" |
| 2024-12-19 11:47:56 +0100 | <mreh> | the graphics API |
| 2024-12-19 11:48:05 +0100 | <mari-estel> | thanks i had already seen |
| 2024-12-19 11:48:27 +0100 | <mreh> | Vulkan pipelines are "almost entirely immutable" I've been told |
| 2024-12-19 11:48:37 +0100 | <mreh> | seems like a good fit |
| 2024-12-19 11:48:56 +0100 | rvalue | (~rvalue@user/rvalue) (Ping timeout: 265 seconds) |
| 2024-12-19 11:49:34 +0100 | <absence> | opqdonut: No, it's Either a b. If you want to mappend all the as and bs separately, you end up with (a,b), or if you want to filter them separately, you need (a->Bool, b->Bool), right? |
| 2024-12-19 11:50:40 +0100 | <opqdonut> | absence: Either a b is kind of one way to express the generators of ([a],[b]) |
| 2024-12-19 11:51:04 +0100 | <opqdonut> | so your basically projecting Either a b -> ([a],[b]) in the natural way, and then doing mappend in ([a],[b]) |
| 2024-12-19 11:51:08 +0100 | <opqdonut> | *you're |
| 2024-12-19 11:51:14 +0100 | mari-estel | (~mari-este@user/mari-estel) (Quit: overflow) |
| 2024-12-19 11:51:26 +0100 | <opqdonut> | or that's at least one perspective on this |
| 2024-12-19 11:51:31 +0100 | <absence> | Ah, now I see what you mean. |
| 2024-12-19 11:52:48 +0100 | sawilagar | (~sawilagar@user/sawilagar) sawilagar |
| 2024-12-19 11:53:46 +0100 | michalz | (~michalz@185.246.207.217) (Ping timeout: 252 seconds) |
| 2024-12-19 11:59:34 +0100 | CiaoSen | (~Jura@2a05:5800:2d8:3500:ca4b:d6ff:fec1:99da) (Ping timeout: 265 seconds) |
| 2024-12-19 12:01:01 +0100 | <absence> | opqdonut: The word generator is used in many different ways, so it's hard to search for. Do you know of a reference? |
| 2024-12-19 12:01:20 +0100 | <opqdonut> | https://en.wikipedia.org/wiki/Generator_(mathematics) |
| 2024-12-19 12:01:44 +0100 | <opqdonut> | https://en.wikipedia.org/wiki/Monoid#Generators |
| 2024-12-19 12:06:03 +0100 | dsrt^ | (~dsrt@c-98-242-74-66.hsd1.ga.comcast.net) (Ping timeout: 246 seconds) |
| 2024-12-19 12:06:42 +0100 | <opqdonut> | there are a lot of ways in which products and sums are duals, but I can't figure out how that'd apply to this thing |
| 2024-12-19 12:08:10 +0100 | <absence> | opqdonut: Thanks! At first glance that seems more abstract than what I'm looking for, as I'm more interested in specific relationships like "I have one of several possibilities, but I don't know which, so I must know how to deal with all of them". |
| 2024-12-19 12:08:22 +0100 | <opqdonut> | oh right: Either a b -> r can be expressed algebraically as r^(a+b) which is the same as r^a*r^b which is (a->r, a->b) in haskell speak |
| 2024-12-19 12:09:15 +0100 | <jackdk> | opqdonut: I think your final tuple should be `(a->r,b->r)` |
| 2024-12-19 12:09:20 +0100 | <opqdonut> | yes |
| 2024-12-19 12:10:16 +0100 | housemate | (~housemate@246.224.218.139.sta.wbroadband.net.au) (Ping timeout: 252 seconds) |
| 2024-12-19 12:12:20 +0100 | <opqdonut> | there was some work on modelling collections algebraically... IIRC e^a was equivalent to Set a, and we could use this to get the equivalence Set (Either a b) == e^(a+b) == e^a*e^b == (Set a, Set b), which is what absence's original question was about |
| 2024-12-19 12:13:12 +0100 | <opqdonut> | (it needs to be e^a because the derivative is the type of one-whole contexts, and the type of one-whole contexts of a set is a set, in other words D(e^a) = e^a ...) |
| 2024-12-19 12:13:20 +0100 | <opqdonut> | (I can't remember the name of the paper though) |
| 2024-12-19 12:13:42 +0100 | <opqdonut> | *one-hole |
| 2024-12-19 12:13:46 +0100 | dunj3 | (~dunj3@h1765027.stratoserver.net) |
| 2024-12-19 12:15:21 +0100 | merijn | (~merijn@77.242.116.146) (Ping timeout: 276 seconds) |
| 2024-12-19 12:15:36 +0100 | <opqdonut> | here's the famous paper on derivatives of types: http://strictlypositive.org/diff.pdf |
| 2024-12-19 12:15:46 +0100 | rvalue | (~rvalue@user/rvalue) rvalue |
| 2024-12-19 12:19:19 +0100 | LainExperiments | (~LainExper@user/LainExperiments) LainExperiments |
| 2024-12-19 12:23:39 +0100 | <hellwolf> | I woke up today, and used yoneda embedding: https://play.haskell.org/saved/n95XGrSf It seems too trivial, on hindsight, since when I made the match function I had not thought of yoneda what so ever. |
| 2024-12-19 12:24:32 +0100 | <hellwolf> | fixed a typo after reading myself: https://play.haskell.org/saved/TygOIulM |
| 2024-12-19 12:25:11 +0100 | xff0x | (~xff0x@182.169.73.28) (Ping timeout: 265 seconds) |
| 2024-12-19 12:25:15 +0100 | <Leary> | absence: Perhaps "coproduct". Sums and products are categorically dual; products in the dual category of C are given by coproducts (sums) in C. |
| 2024-12-19 12:30:10 +0100 | dsrt^ | (dsrt@c-98-242-74-66.hsd1.ga.comcast.net) |
| 2024-12-19 12:35:01 +0100 | tnt1 | (~Thunderbi@user/tnt1) (Ping timeout: 252 seconds) |
| 2024-12-19 12:35:16 +0100 | tnt1 | (~Thunderbi@user/tnt1) tnt1 |
| 2024-12-19 12:39:32 +0100 | merijn | (~merijn@77.242.116.146) merijn |
| 2024-12-19 12:39:46 +0100 | <absence> | Leary: Thanks, I'm aware of that, at least informally. Maybe what I'm missing is "simply" intuition. |
| 2024-12-19 12:40:41 +0100 | mari-estel | (~mari-este@user/mari-estel) mari-estel |
| 2024-12-19 12:41:21 +0100 | gvg | (~dcd@user/gvg) (Ping timeout: 276 seconds) |
| 2024-12-19 12:45:56 +0100 | michalz | (~michalz@185.246.207.221) |
| 2024-12-19 12:49:04 +0100 | mari-estel | (~mari-este@user/mari-estel) (Quit: overflow) |
| 2024-12-19 12:50:19 +0100 | mari-estel | (~mari-este@user/mari-estel) mari-estel |
| 2024-12-19 12:50:51 +0100 | <hellwolf> | https://play.haskell.org/saved/QPe3WuiN added another functional dependency and a example application of it in an additional comment. |
| 2024-12-19 12:51:37 +0100 | michalz | (~michalz@185.246.207.221) (Quit: ZNC 1.9.0 - https://znc.in) |
| 2024-12-19 12:52:24 +0100 | mari-estel | (~mari-este@user/mari-estel) (Client Quit) |
| 2024-12-19 12:53:09 +0100 | dsrt^ | (dsrt@c-98-242-74-66.hsd1.ga.comcast.net) (Ping timeout: 244 seconds) |
| 2024-12-19 12:54:08 +0100 | michalz | (~michalz@185.246.207.197) |
| 2024-12-19 12:54:24 +0100 | darkling | (~darkling@2001-ba8-1f1-f0e6-0-0-0-2.autov6rev.bitfolk.space) (Summoning his cosmis powers, and glowing slightly from his toes...) |
| 2024-12-19 12:54:33 +0100 | darkling | (~darkling@2001-ba8-1f1-f0e6-0-0-0-2.autov6rev.bitfolk.space) darkling |
| 2024-12-19 12:56:15 +0100 | <vpan> | geekosaur: well, I started by trying the `Maybe` example - I've put the code fragments into a file and tried loading into ghci, see https://paste.tomsmeding.com/1Ls1IoYD . I disabled the email function as I didn't find where to import `member` from. |
| 2024-12-19 12:56:17 +0100 | <vpan> | The `Either` sample seems to have a similar problem. |
| 2024-12-19 12:57:17 +0100 | <geekosaur> | shouldn't that be `elem`? (with the backticks, since it's being used infix) |
| 2024-12-19 12:58:18 +0100 | lortabac | (~lortabac@2a01:e0a:541:b8f0:55ab:e185:7f81:54a4) |
| 2024-12-19 12:58:25 +0100 | <geekosaur> | yes, you have the usual confusion about IO there |
| 2024-12-19 12:58:48 +0100 | <geekosaur> | and, well, tcreateUser is in IO, you can't all of a sudden sewitch it into Maybe |
| 2024-12-19 12:59:01 +0100 | <geekosaur> | use let instead of <- |
| 2024-12-19 13:00:04 +0100 | caconym | (~caconym@user/caconym) (Quit: bye) |
| 2024-12-19 13:00:48 +0100 | <vpan> | geekosaur: I understand, but the code is straight from the mmhaskell article and seems to be broken, which I found a little surprising |
| 2024-12-19 13:01:23 +0100 | caconym | (~caconym@user/caconym) caconym |
| 2024-12-19 13:01:28 +0100 | mud | (~mud@user/kadoban) (Remote host closed the connection) |
| 2024-12-19 13:01:53 +0100 | mud | (~mud@user/kadoban) kadoban |
| 2024-12-19 13:01:56 +0100 | <geekosaur> | hm, yes, that does look broken, now that I look again |
| 2024-12-19 13:02:13 +0100 | <geekosaur> | I think the lesson here is "don't trust random pages on the Internet" |
| 2024-12-19 13:04:19 +0100 | <vpan> | right, and here I thought if you were trying to teach beginners at least compiling the code would be good practice. :) I had read other mmhaskell articles before and they seemed fine, so was just checking whether it is me missing something or just another case of someone being wrong on the internet. :) |
| 2024-12-19 13:05:44 +0100 | <geekosaur> | thing is, they're not even using it as a monad, since theyre still doing a case on it |
| 2024-12-19 13:05:50 +0100 | michalz | (~michalz@185.246.207.197) (Ping timeout: 260 seconds) |
| 2024-12-19 13:05:52 +0100 | <geekosaur> | the only monad there is IO |
| 2024-12-19 13:06:53 +0100 | <geekosaur> | the (Either a) monad would "fail" (see Control.Monad.Fail) on a Left, and give you the result on Right |
| 2024-12-19 13:21:13 +0100 | dsrt^ | (~dsrt@c-98-242-74-66.hsd1.ga.comcast.net) |
| 2024-12-19 13:21:15 +0100 | michalz | (~michalz@185.246.207.193) |
| 2024-12-19 13:24:55 +0100 | CiaoSen | (~Jura@2a05:5800:2d8:3500:ca4b:d6ff:fec1:99da) CiaoSen |
| 2024-12-19 13:28:54 +0100 | michalz | (~michalz@185.246.207.193) (Ping timeout: 272 seconds) |
| 2024-12-19 13:34:22 +0100 | jero98772 | (~jero98772@2a00:1fa0:4122:828f:7f98:47ba:81b9:d7a4) |
| 2024-12-19 13:35:23 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Read error: Connection reset by peer) |
| 2024-12-19 13:36:46 +0100 | jero98772 | (~jero98772@2a00:1fa0:4122:828f:7f98:47ba:81b9:d7a4) (Client Quit) |
| 2024-12-19 13:44:07 +0100 | dsrt^ | (~dsrt@c-98-242-74-66.hsd1.ga.comcast.net) (Ping timeout: 272 seconds) |
| 2024-12-19 13:44:56 +0100 | vanishingideal | (~vanishing@user/vanishingideal) (Quit: leaving) |
| 2024-12-19 13:45:25 +0100 | vanishingideal | (~vanishing@user/vanishingideal) vanishingideal |
| 2024-12-19 13:46:31 +0100 | ethantwardy | (user@user/ethantwardy) (Quit: WeeChat 4.4.2) |
| 2024-12-19 13:47:12 +0100 | lucabtz | (~lucabtz@user/lucabtz) (Leaving) |
| 2024-12-19 13:58:09 +0100 | lortabac | (~lortabac@2a01:e0a:541:b8f0:55ab:e185:7f81:54a4) (Quit: WeeChat 4.4.2) |
| 2024-12-19 14:01:06 +0100 | r-sta | (~r-sta@sgyl-37-b2-v4wan-168528-cust2421.vm6.cable.virginm.net) |
| 2024-12-19 14:01:23 +0100 | gawen | (~gawen@user/gawen) (Quit: cya) |
| 2024-12-19 14:01:37 +0100 | merijn | (~merijn@77.242.116.146) (Ping timeout: 248 seconds) |
| 2024-12-19 14:02:19 +0100 | homo_ | (~homo@82-128-217-24.bb.dnainternet.fi) |
| 2024-12-19 14:02:23 +0100 | homo_ | (~homo@82-128-217-24.bb.dnainternet.fi) (Changing host) |
| 2024-12-19 14:02:23 +0100 | homo_ | (~homo@user/homo) homo |
| 2024-12-19 14:02:46 +0100 | gawen | (~gawen@user/gawen) gawen |
| 2024-12-19 14:02:46 +0100 | homo | (~homo@user/homo) (Read error: Connection reset by peer) |
| 2024-12-19 14:02:52 +0100 | <r-sta> | iv got this weird niggling kind of question to do with i think what people call idiomatic approaches |
| 2024-12-19 14:03:05 +0100 | <r-sta> | in terms of what consitutes a valid / useful abstraction |
| 2024-12-19 14:03:15 +0100 | homo_ | homo |
| 2024-12-19 14:03:31 +0100 | <r-sta> | i end up having to like jump through hoops i set myself to justify an approach is somehow cannonical or something |
| 2024-12-19 14:04:22 +0100 | <r-sta> | the more i work with things i would have be "libraries" if i put them on hackage, the more i end up just kind of using them as a style that other things can emulate |
| 2024-12-19 14:04:50 +0100 | <r-sta> | idk if you could use map as an annalogy, in terms of its recursive implementation, and how other functions might follow similar but slightly different implementations |
| 2024-12-19 14:08:17 +0100 | tnt2 | (~Thunderbi@user/tnt1) tnt1 |
| 2024-12-19 14:08:39 +0100 | merijn | (~merijn@77.242.116.146) merijn |
| 2024-12-19 14:09:05 +0100 | xff0x | (~xff0x@2405:6580:b080:900:deb8:42d3:dcec:a1de) |
| 2024-12-19 14:10:08 +0100 | tnt1 | (~Thunderbi@user/tnt1) (Ping timeout: 244 seconds) |
| 2024-12-19 14:10:08 +0100 | tnt2 | tnt1 |
| 2024-12-19 14:14:50 +0100 | <r-sta> | like, how do describe the natural numbers, its a functor? |
| 2024-12-19 14:15:11 +0100 | <r-sta> | (Num a,Functor f) => f a |
| 2024-12-19 14:15:38 +0100 | <r-sta> | and then, whatever central "object" like functor or whatever, like, serves as this useful abstraction |
| 2024-12-19 14:16:25 +0100 | <r-sta> | i was arguing the correct abstraction is actualy a "sheduled" functor |
| 2024-12-19 14:16:34 +0100 | <r-sta> | but i ended up just modeling this as a sequential store |
| 2024-12-19 14:16:48 +0100 | <r-sta> | im confused now about the abstraction and how it fits in in terms of librification |
| 2024-12-19 14:17:37 +0100 | <r-sta> | its like this weird argument like "no, you dont just map them, they appear in order, its not a functor it needs an order its probably traversable or something" |
| 2024-12-19 14:18:32 +0100 | michalz | (~michalz@185.246.207.215) |
| 2024-12-19 14:18:46 +0100 | <r-sta> | and then like, well you could have a sheduled functor, but what your actually doing is a sequential operation series of persistent stores, which loosely models the natural numbers, just by virtue of appearing in a sequence, like how you have a counting on the natural numbers which is what you were modelling with the traversable abstraction! |
| 2024-12-19 14:19:27 +0100 | <r-sta> | ("persistent" because like, 1 stays the same... the "first" ... dog, or whatever...) |
| 2024-12-19 14:19:48 +0100 | <r-sta> | and then i guess you have a group generator? |
| 2024-12-19 14:20:08 +0100 | <r-sta> | so this kind of cascading store opperation which populates this "container"... |
| 2024-12-19 14:21:32 +0100 | <r-sta> | and what i was trying to argue is that when your doing ML, the sequence of improvements on an object, such as a self learning opperator or the target of learning, fits into this sequential morphism setup, so the "abstraction" of the "shedule" which amounts to something almost like an unfold... |
| 2024-12-19 14:22:03 +0100 | <r-sta> | "the machine is like a bunch of machines of increasing complexity as you train them sequentially" |
| 2024-12-19 14:22:06 +0100 | <r-sta> | or something |
| 2024-12-19 14:22:19 +0100 | <r-sta> | is a statement that uses this abstraction to basically define the thing! |
| 2024-12-19 14:22:42 +0100 | merijn | (~merijn@77.242.116.146) (Ping timeout: 252 seconds) |
| 2024-12-19 14:23:29 +0100 | <r-sta> | (theres something mad in differential geometry to do with the geometry of the learning process) |
| 2024-12-19 14:23:39 +0100 | <r-sta> | (its a path...) |
| 2024-12-19 14:24:12 +0100 | <r-sta> | "automorphic curves in the category of automorphic opperators" or smt |
| 2024-12-19 14:24:19 +0100 | merijn | (~merijn@77.242.116.146) merijn |
| 2024-12-19 14:24:28 +0100 | <r-sta> | and you get like "very fast learning paths" |
| 2024-12-19 14:24:50 +0100 | <r-sta> | like, im sure it makes sense to have the path be the central abstraction... |
| 2024-12-19 14:26:41 +0100 | <r-sta> | "its the next one" |
| 2024-12-19 14:27:37 +0100 | r-sta | (~r-sta@sgyl-37-b2-v4wan-168528-cust2421.vm6.cable.virginm.net) (Quit: Client closed) |
| 2024-12-19 14:32:51 +0100 | gvg | (~dcd@user/gvg) gvg |
| 2024-12-19 14:35:51 +0100 | merijn | (~merijn@77.242.116.146) (Ping timeout: 246 seconds) |
| 2024-12-19 14:37:24 +0100 | merijn | (~merijn@77.242.116.146) merijn |
| 2024-12-19 14:37:59 +0100 | ljdarj | (~Thunderbi@user/ljdarj) ljdarj |
| 2024-12-19 14:42:07 +0100 | merijn | (~merijn@77.242.116.146) (Ping timeout: 252 seconds) |
| 2024-12-19 14:46:33 +0100 | SlackCoder | (~SlackCode@64-94-63-8.ip.weststar.net.ky) SlackCoder |
| 2024-12-19 14:49:20 +0100 | weary-traveler | (~user@user/user363627) user363627 |
| 2024-12-19 14:53:38 +0100 | merijn | (~merijn@77.242.116.146) merijn |
| 2024-12-19 14:53:40 +0100 | rekahsoft | (~rekahsoft@76.69.85.220) rekahsoft |
| 2024-12-19 14:54:35 +0100 | malte | (~malte@mal.tc) (Remote host closed the connection) |
| 2024-12-19 14:54:53 +0100 | malte | (~malte@mal.tc) malte |
| 2024-12-19 14:56:42 +0100 | cheater | (~Username@user/cheater) cheater |
| 2024-12-19 14:58:11 +0100 | merijn | (~merijn@77.242.116.146) (Ping timeout: 244 seconds) |
| 2024-12-19 15:00:13 +0100 | ubert1 | (~Thunderbi@2a02:8109:ab8a:5a00:636:48a0:bc95:5cdf) ubert |
| 2024-12-19 15:02:02 +0100 | weary-traveler | (~user@user/user363627) (Remote host closed the connection) |
| 2024-12-19 15:04:05 +0100 | ubert | (~Thunderbi@2a02:8109:ab8a:5a00:f6f5:1546:1c7e:72ab) (Ping timeout: 244 seconds) |
| 2024-12-19 15:04:05 +0100 | ubert1 | ubert |
| 2024-12-19 15:08:09 +0100 | simplystuart | (~simplystu@c-75-75-152-164.hsd1.pa.comcast.net) |
| 2024-12-19 15:08:26 +0100 | MAX_DAVIDSON_REA | (~MAX_DAVID@64.251.61.168) |
| 2024-12-19 15:09:13 +0100 | LainExperiments | (~LainExper@user/LainExperiments) (Quit: Client closed) |
| 2024-12-19 15:09:37 +0100 | merijn | (~merijn@77.242.116.146) merijn |
| 2024-12-19 15:11:30 +0100 | SlackCoder | (~SlackCode@64-94-63-8.ip.weststar.net.ky) (Ping timeout: 276 seconds) |
| 2024-12-19 15:14:13 +0100 | merijn | (~merijn@77.242.116.146) (Ping timeout: 248 seconds) |
| 2024-12-19 15:17:23 +0100 | MAX_DAVIDSON_REA | (~MAX_DAVID@64.251.61.168) (Quit: Client closed) |
| 2024-12-19 15:18:08 +0100 | homo | (~homo@user/homo) (Quit: Quit) |
| 2024-12-19 15:18:18 +0100 | thirteenyearoldb | (~thirteeny@64.251.61.168) |
| 2024-12-19 15:18:23 +0100 | homo | (~homo@user/homo) homo |
| 2024-12-19 15:20:07 +0100 | thirteenyearoldb | (~thirteeny@64.251.61.168) (Client Quit) |
| 2024-12-19 15:21:05 +0100 | thirteenyearoldb | (~thirteeny@64.251.61.168) |
| 2024-12-19 15:22:49 +0100 | merijn | (~merijn@77.242.116.146) merijn |
| 2024-12-19 15:31:46 +0100 | thirteenyearoldb | (~thirteeny@64.251.61.168) () |
| 2024-12-19 15:32:38 +0100 | dolio | (~dolio@130.44.140.168) (Quit: ZNC 1.9.1 - https://znc.in) |
| 2024-12-19 15:34:20 +0100 | ubert1 | (~Thunderbi@2a02:8109:ab8a:5a00:241b:e6b5:8a3b:fcd8) ubert |
| 2024-12-19 15:35:45 +0100 | pavonia | (~user@user/siracusa) siracusa |
| 2024-12-19 15:36:09 +0100 | dolio | (~dolio@130.44.140.168) dolio |
| 2024-12-19 15:36:48 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Ping timeout: 264 seconds) |
| 2024-12-19 15:38:19 +0100 | ubert | (~Thunderbi@2a02:8109:ab8a:5a00:636:48a0:bc95:5cdf) (Ping timeout: 245 seconds) |
| 2024-12-19 15:38:19 +0100 | ubert1 | ubert |
| 2024-12-19 15:38:19 +0100 | dolio | (~dolio@130.44.140.168) (Client Quit) |
| 2024-12-19 15:41:21 +0100 | dolio | (~dolio@130.44.140.168) dolio |
| 2024-12-19 15:44:30 +0100 | iamsleepy | (~weechat@2a01:4f9:3070:feff:54d:81b5:739b:c728) iamsleepy |
| 2024-12-19 15:44:46 +0100 | Sgeo | (~Sgeo@user/sgeo) Sgeo |
| 2024-12-19 15:52:59 +0100 | turlando | (~turlando@user/turlando) (Quit: No Ping reply in 180 seconds.) |
| 2024-12-19 15:54:15 +0100 | turlando | (~turlando@user/turlando) turlando |
| 2024-12-19 15:58:49 +0100 | dolio | (~dolio@130.44.140.168) (Ping timeout: 265 seconds) |
| 2024-12-19 16:00:05 +0100 | CiaoSen | (~Jura@2a05:5800:2d8:3500:ca4b:d6ff:fec1:99da) (Ping timeout: 248 seconds) |
| 2024-12-19 16:03:22 +0100 | dolio | (~dolio@130.44.140.168) dolio |
| 2024-12-19 16:04:00 +0100 | merijn | (~merijn@77.242.116.146) (Ping timeout: 252 seconds) |
| 2024-12-19 16:05:36 +0100 | weary-traveler | (~user@user/user363627) user363627 |
| 2024-12-19 16:10:26 +0100 | merijn | (~merijn@77.242.116.146) merijn |
| 2024-12-19 16:11:51 +0100 | xff0x_ | (~xff0x@2405:6580:b080:900:47af:5bec:f5b4:7548) |
| 2024-12-19 16:14:31 +0100 | xff0x | (~xff0x@2405:6580:b080:900:deb8:42d3:dcec:a1de) (Ping timeout: 252 seconds) |
| 2024-12-19 16:21:15 +0100 | lortabac | (~lortabac@2a01:e0a:541:b8f0:55ab:e185:7f81:54a4) lortabac |
| 2024-12-19 16:22:03 +0100 | LainExperiments | (~LainExper@user/LainExperiments) LainExperiments |
| 2024-12-19 16:22:47 +0100 | LainExperiments | (~LainExper@user/LainExperiments) (Client Quit) |
| 2024-12-19 16:26:38 +0100 | lortabac | (~lortabac@2a01:e0a:541:b8f0:55ab:e185:7f81:54a4) (Quit: WeeChat 4.4.2) |
| 2024-12-19 16:27:09 +0100 | <hellwolf> | I have written a closure function using Data.Set https://play.haskell.org/saved/R6VP6J8M I am sure it is not the most efficient one, and might even be wrong.. anyone has time to have a look and critique? |
| 2024-12-19 16:30:02 +0100 | vpan | (~vpan@212.117.1.172) (Quit: Leaving.) |
| 2024-12-19 16:30:11 +0100 | <hellwolf> | And I haven't yet found an interesting example to test, outside of the context of where I cdtually use this. |
| 2024-12-19 16:30:54 +0100 | <hellwolf> | (I was thinking of a number that generate a list until the Set stops growing, but I don't play with maths enough to come up with such an example on top of my head.) |
| 2024-12-19 16:40:18 +0100 | vanishingideal | (~vanishing@user/vanishingideal) (Ping timeout: 252 seconds) |
| 2024-12-19 16:41:57 +0100 | vanishingideal | (~vanishing@user/vanishingideal) vanishingideal |
| 2024-12-19 16:46:45 +0100 | <Leary> | hellwolf: https://play.haskell.org/saved/EsoKddpA |
| 2024-12-19 16:47:30 +0100 | <hellwolf> | sorry, it should be (a -> [a]) |
| 2024-12-19 16:47:45 +0100 | <hellwolf> | I should have written a signature, but I took it out from a where clause |
| 2024-12-19 16:47:56 +0100 | <Leary> | You can swap `S.map` with `foldMap` then. |
| 2024-12-19 16:48:48 +0100 | <hellwolf> | closure :: Ord a => (a -> [a]) -> [a] -> Set.Set a -> Set.Set a |
| 2024-12-19 16:49:32 +0100 | <Leary> | What is the point of the extra list argument? Why not just `Ord a => (a -> Set a) -> Set a -> Set a`? |
| 2024-12-19 16:50:45 +0100 | vanishingideal | (~vanishing@user/vanishingideal) (Ping timeout: 252 seconds) |
| 2024-12-19 16:52:46 +0100 | vanishingideal | (~vanishing@user/vanishingideal) vanishingideal |
| 2024-12-19 16:54:43 +0100 | <hellwolf> | good question, skill issue. |
| 2024-12-19 16:55:01 +0100 | <hellwolf> | let me do a dropin replacement, and see if everything still works. |
| 2024-12-19 16:56:42 +0100 | <int-e> | Leary: presumably one of those was an accumulator |
| 2024-12-19 16:57:11 +0100 | <hellwolf> | Ah, my extra "xs" parameters help not to recaculate more than needed. |
| 2024-12-19 16:57:35 +0100 | <hellwolf> | but your way seems doing it too. |
| 2024-12-19 17:00:14 +0100 | <int-e> | Leary: https://paste.tomsmeding.com/PqXVAv3y is something I came up with some years ago |
| 2024-12-19 17:01:10 +0100 | <int-e> | Leary: so very similar, except that new elements are not just generated based off a single element but also based off inferences made previously |
| 2024-12-19 17:01:43 +0100 | gorignak | (~gorignak@user/gorignak) (Ping timeout: 272 seconds) |
| 2024-12-19 17:02:06 +0100 | <int-e> | Leary: I have a corresponding incremental version too (the result list can be consumed lazily): https://paste.tomsmeding.com/6srbBNEH |
| 2024-12-19 17:02:46 +0100 | <int-e> | hmm |
| 2024-12-19 17:03:10 +0100 | <int-e> | hellwolf might care more |
| 2024-12-19 17:06:37 +0100 | <hellwolf> | https://play.haskell.org/saved/tUrCHhqy |
| 2024-12-19 17:06:37 +0100 | <hellwolf> | int-e I am gonna put your version in a moment |
| 2024-12-19 17:06:46 +0100 | <int-e> | the underlying mental model was Horn inference... p1,p2,p3 -> q derives q if the single x is one of p1,p2,p3, {p1,p2,p3} is a subset of the known inferences |
| 2024-12-19 17:08:04 +0100 | <hellwolf> | ah, sorry, I can't understand your version fast enough... I need to leave it there for a while. The latest link of mine has both my naive version and Leary's |
| 2024-12-19 17:09:06 +0100 | <int-e> | no worries. it's not for efficiency anyway, it's mostly a bit more general |
| 2024-12-19 17:09:31 +0100 | <int-e> | in a way that I thought might be interesting |
| 2024-12-19 17:16:17 +0100 | ubert | (~Thunderbi@2a02:8109:ab8a:5a00:241b:e6b5:8a3b:fcd8) (Remote host closed the connection) |
| 2024-12-19 17:16:34 +0100 | ubert | (~Thunderbi@2a02:8109:ab8a:5a00:fbee:83c2:2fbc:cebb) ubert |
| 2024-12-19 17:17:37 +0100 | <hellwolf> | https://play.haskell.org/saved/tlycglQO small fixes. |
| 2024-12-19 17:18:26 +0100 | <hellwolf> | Also, I probably have butchered Leary's version, and replaced a piece of it with "S.fromList (concatMap f new)" |
| 2024-12-19 17:18:48 +0100 | <hellwolf> | Anyways, not here for the performance, per se... Just sourcing some ideas to learn. |
| 2024-12-19 17:19:24 +0100 | <int-e> | you can do the same thing with HashSet and it might be faster |
| 2024-12-19 17:20:08 +0100 | <hellwolf> | Right, actually I don't need the Ord. |
| 2024-12-19 17:20:34 +0100 | <hellwolf> | but it's not from containers package... I will skip for now. I will optimize it another time. |
| 2024-12-19 17:21:41 +0100 | <int-e> | the corresponding call for that `saturate` would be `saturate [512] (\x _ > g x)` |
| 2024-12-19 17:21:55 +0100 | <int-e> | ...grammar borked, oh well |
| 2024-12-19 17:22:21 +0100 | <int-e> | and I also broke the arrow in (\x _ -> g x) |
| 2024-12-19 17:22:34 +0100 | <int-e> | @pl \x _ > g x -- const . g I assume |
| 2024-12-19 17:22:34 +0100 | <lambdabot> | (line 1, column 6): |
| 2024-12-19 17:22:34 +0100 | <lambdabot> | unexpected ">" |
| 2024-12-19 17:22:34 +0100 | <lambdabot> | expecting pattern or "->" |
| 2024-12-19 17:22:42 +0100 | <int-e> | @pl \x _ -> g x |
| 2024-12-19 17:22:56 +0100 | <lambdabot> | const . g |
| 2024-12-19 17:23:24 +0100 | ubert | (~Thunderbi@2a02:8109:ab8a:5a00:fbee:83c2:2fbc:cebb) (Ping timeout: 265 seconds) |
| 2024-12-19 17:24:26 +0100 | <int-e> | (you can easily modify `saturate` to not pass the second argument to `sat1` and then the only remaining difference is passing a set or a list for the seed inferences) |
| 2024-12-19 17:24:31 +0100 | <hellwolf> | https://play.haskell.org/saved/08Mac53g |
| 2024-12-19 17:24:34 +0100 | <hellwolf> | wit yours |
| 2024-12-19 17:28:33 +0100 | Square2 | (~Square@user/square) Square |
| 2024-12-19 17:30:09 +0100 | <hellwolf> | and I didn't know that foldl' was not available a few bases ago |
| 2024-12-19 17:30:20 +0100 | <hellwolf> | *not available from Prelude |
| 2024-12-19 17:30:27 +0100 | agent314 | (~quassel@104.223.118.58) agent314 |
| 2024-12-19 17:30:31 +0100 | <int-e> | it was always available from Data.List |
| 2024-12-19 17:33:36 +0100 | agent314 | (~quassel@104.223.118.58) (Client Quit) |
| 2024-12-19 17:33:39 +0100 | ash3en | (~Thunderbi@2a03:7846:b6eb:101:93ac:a90a:da67:f207) ash3en |
| 2024-12-19 17:36:23 +0100 | alexherbo2 | (~alexherbo@2a02-8440-350c-d1b2-f913-af6a-c348-0a7f.rev.sfr.net) (Remote host closed the connection) |
| 2024-12-19 17:36:32 +0100 | agent314 | (~quassel@104.223.118.58) agent314 |
| 2024-12-19 17:36:41 +0100 | alexherbo2 | (~alexherbo@2a02-8440-350c-d1b2-f913-af6a-c348-0a7f.rev.sfr.net) alexherbo2 |
| 2024-12-19 17:37:05 +0100 | ash3en1 | (~Thunderbi@146.70.124.222) ash3en |
| 2024-12-19 17:38:23 +0100 | ash3en | (~Thunderbi@2a03:7846:b6eb:101:93ac:a90a:da67:f207) (Ping timeout: 265 seconds) |
| 2024-12-19 17:38:23 +0100 | ash3en1 | ash3en |
| 2024-12-19 17:40:04 +0100 | codaraxis | (~codaraxis@user/codaraxis) Codaraxis |
| 2024-12-19 17:40:31 +0100 | <ski> | hellwolf : fwiw, what you're computing is (also) called "fixed-point iteration" (in math, logic & computing, generally), and the specific optimization of only reacting to new elements each round ("my extra \"xs\" parameters help not to recaculate more than needed") is called "semi-naïve evaluation" (in the context of deductive databases) |
| 2024-12-19 17:45:30 +0100 | <ski> | (although, the setting of the latter is a little bit more general, in that there you're generating a set of new elements, not merely from individual already generated elements, but also from subsets of already generated elements. so, if you have `a' *and* `b' generated, that may e.g. allow you to now generate `c'. so `a' might be an old element, and `b' might be newly generated in last round, so you need to |
| 2024-12-19 17:45:36 +0100 | <ski> | consider subsets where at least one element is new (iow combining new with new&old), for the (semi-naïve) optimization) |
| 2024-12-19 17:45:37 +0100 | machinedgod | (~machinedg@d108-173-18-100.abhsia.telus.net) (Ping timeout: 248 seconds) |
| 2024-12-19 17:46:26 +0100 | alexherbo2 | (~alexherbo@2a02-8440-350c-d1b2-f913-af6a-c348-0a7f.rev.sfr.net) (Remote host closed the connection) |
| 2024-12-19 17:47:13 +0100 | pointlessslippe1 | (~pointless@62.106.85.17) (Quit: ZNC - http://znc.in) |
| 2024-12-19 17:47:15 +0100 | alexherbo2 | (~alexherbo@2a02-8440-350c-d1b2-4cce-5b9b-3d2d-31a1.rev.sfr.net) alexherbo2 |
| 2024-12-19 17:50:21 +0100 | <hellwolf> | right, I am aware of it's a fixed point. I am not proficient enough to write one for this case :) |
| 2024-12-19 17:51:05 +0100 | alexherbo2 | (~alexherbo@2a02-8440-350c-d1b2-4cce-5b9b-3d2d-31a1.rev.sfr.net) (Remote host closed the connection) |
| 2024-12-19 17:55:52 +0100 | <ski> | well, i think int-e's generalization does allow doing this (at the cost of some extra fiddling to e.g. represent the `a,b -> c' case both when `a' is the new element, and when `b' is .. something along the lines is `\x xs -> if x == a && b `S.member` xs || x == b && a `S.member` xs then c : ... else ...') |
| 2024-12-19 17:59:14 +0100 | pointlessslippe1 | (~pointless@62.106.85.17) pointlessslippe1 |
| 2024-12-19 18:00:18 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) bitdex |
| 2024-12-19 18:00:36 +0100 | agent314 | (~quassel@104.223.118.58) (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) |
| 2024-12-19 18:00:52 +0100 | ft | (~ft@p508db9c7.dip0.t-ipconnect.de) (Ping timeout: 252 seconds) |
| 2024-12-19 18:03:21 +0100 | comerijn | (~merijn@77.242.116.146) merijn |
| 2024-12-19 18:04:35 +0100 | segfaultfizzbuzz | (~segfaultf@23-93-87-166.dedicated.static.sonic.net) segfaultfizzbuzz |
| 2024-12-19 18:05:57 +0100 | merijn | (~merijn@77.242.116.146) (Ping timeout: 244 seconds) |
| 2024-12-19 18:05:57 +0100 | hellwolf | (~user@384c-9f11-ae01-0420-0f00-4d40-07d0-2001.sta.estpak.ee) (Read error: Connection reset by peer) |
| 2024-12-19 18:06:12 +0100 | hellwolf | (~user@64da-33e4-b3ed-391e-0f00-4d40-07d0-2001.sta.estpak.ee) hellwolf |
| 2024-12-19 18:08:19 +0100 | comerijn | (~merijn@77.242.116.146) (Ping timeout: 252 seconds) |
| 2024-12-19 18:09:28 +0100 | weary-traveler | (~user@user/user363627) (Remote host closed the connection) |
| 2024-12-19 18:14:27 +0100 | <int-e> | ski: thanks for the "deductive database" keyword |
| 2024-12-19 18:18:21 +0100 | briandaed | (~root@user/briandaed) (Quit: Lost terminal) |
| 2024-12-19 18:20:49 +0100 | <int-e> | ski: there's a whole parallel world in SAT solving (unit propagation, and watched literals to speed up scanning the clauses for new candidates) |
| 2024-12-19 18:21:49 +0100 | <int-e> | (which would lead to very different interface) |
| 2024-12-19 18:23:58 +0100 | ft | (~ft@p508db9c7.dip0.t-ipconnect.de) ft |
| 2024-12-19 18:26:15 +0100 | tomsmeding | is adding the brand-new ghc 9.12.1 to the playground |
| 2024-12-19 18:26:24 +0100 | tomsmeding | sees that vector doesn't build with that ghc |
| 2024-12-19 18:26:36 +0100 | tomsmeding | sees the set of compatible packages dwindle before his eyes |
| 2024-12-19 18:29:37 +0100 | ljdarj | (~Thunderbi@user/ljdarj) (Ping timeout: 265 seconds) |
| 2024-12-19 18:31:50 +0100 | sawilagar | (~sawilagar@user/sawilagar) (Quit: Leaving) |
| 2024-12-19 18:35:43 +0100 | <tomsmeding> | well, s/doesn't build/doesn't configure/ |
| 2024-12-19 18:36:48 +0100 | Pixi__ | (~Pixi@user/pixi) (Quit: Leaving) |
| 2024-12-19 18:38:23 +0100 | <tomsmeding> | it does? |
| 2024-12-19 18:38:36 +0100 | ash3en1 | (~Thunderbi@2a03:7846:b6eb:101:93ac:a90a:da67:f207) ash3en |
| 2024-12-19 18:38:53 +0100 | <tomsmeding> | oh I failed reading the cabal configure output |
| 2024-12-19 18:39:10 +0100 | <tomsmeding> | this is not too bad |
| 2024-12-19 18:39:50 +0100 | ash3en | (~Thunderbi@146.70.124.222) (Ping timeout: 244 seconds) |
| 2024-12-19 18:39:50 +0100 | ash3en1 | ash3en |
| 2024-12-19 18:40:01 +0100 | <hellwolf> | danke tomsmeding, a orpattern example would be rad |
| 2024-12-19 18:42:15 +0100 | <tomsmeding> | well the example you can just copy-paste from the docs :) https://downloads.haskell.org/ghc/9.12.1/docs/users_guide/exts/or_patterns.html#extension-OrPatterns |
| 2024-12-19 18:42:26 +0100 | <tomsmeding> | currently building 127 packages :) |
| 2024-12-19 18:47:27 +0100 | dolio | (~dolio@130.44.140.168) (Quit: ZNC 1.9.1 - https://znc.in) |
| 2024-12-19 18:52:50 +0100 | <tomsmeding> | hellwolf: 9.12.1 is up, have a go :) |
| 2024-12-19 18:54:42 +0100 | <tomsmeding> | I use too many :) |
| 2024-12-19 18:54:52 +0100 | <homo> | is that... prolog? |
| 2024-12-19 18:55:12 +0100 | <tomsmeding> | no it's just collapsing multiple patterns that bind no variables into one case |
| 2024-12-19 18:55:17 +0100 | <tomsmeding> | it's semantically uninteresting |
| 2024-12-19 18:56:12 +0100 | mulk | (~mulk@pd951419b.dip0.t-ipconnect.de) (Read error: Connection reset by peer) |
| 2024-12-19 18:56:15 +0100 | <homo> | the joke is that ";" means "or" in prolog |
| 2024-12-19 18:56:50 +0100 | <tomsmeding> | iirc ';' was chosen mostly because it's already reserved syntax that can never be an operator |
| 2024-12-19 18:56:58 +0100 | <tomsmeding> | and it meant nothing in that context |
| 2024-12-19 18:57:16 +0100 | <tomsmeding> | it coinciding with prolog's "or" is just being lucky, I guess |
| 2024-12-19 18:57:41 +0100 | <tomsmeding> | '|' would be very confusing with guards, even if its technically unambiguous |
| 2024-12-19 18:57:49 +0100 | <tomsmeding> | *it's |
| 2024-12-19 18:59:33 +0100 | housemate | (~housemate@149.167.24.31) housemate |
| 2024-12-19 19:03:42 +0100 | tzh | (~tzh@c-76-115-131-146.hsd1.or.comcast.net) |
| 2024-12-19 19:04:42 +0100 | ash3en | (~Thunderbi@2a03:7846:b6eb:101:93ac:a90a:da67:f207) (Quit: ash3en) |
| 2024-12-19 19:12:18 +0100 | <hellwolf> | GREAT! |
| 2024-12-19 19:12:21 +0100 | <hellwolf> | I hope you like my example: https://play.haskell.org/saved/5lhAatk1 |
| 2024-12-19 19:12:55 +0100 | fun-safe-math | (~fun-safe-@24.21.106.247) () |
| 2024-12-19 19:13:11 +0100 | <tomsmeding> | lol |
| 2024-12-19 19:14:36 +0100 | fun-safe-math | (~fun-safe-@24.21.106.247) fun-safe-math |
| 2024-12-19 19:14:42 +0100 | mulk | (~mulk@pd951419b.dip0.t-ipconnect.de) mulk |
| 2024-12-19 19:18:55 +0100 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) (Ping timeout: 265 seconds) |
| 2024-12-19 19:18:56 +0100 | Lord_of_Life_ | (~Lord@user/lord-of-life/x-2819915) Lord_of_Life |
| 2024-12-19 19:19:38 +0100 | fun-safe-math | (~fun-safe-@24.21.106.247) () |
| 2024-12-19 19:20:44 +0100 | ash3en | (~Thunderbi@2a03:7846:b6eb:101:93ac:a90a:da67:f207) ash3en |
| 2024-12-19 19:21:20 +0100 | fun-safe-math | (~fun-safe-@24.21.106.247) fun-safe-math |
| 2024-12-19 19:21:55 +0100 | Lord_of_Life_ | Lord_of_Life |
| 2024-12-19 19:23:33 +0100 | sprotte24 | (~sprotte24@p200300d16f19ee00b46a5b4fb1cae10a.dip0.t-ipconnect.de) |
| 2024-12-19 19:25:39 +0100 | vanishingideal | (~vanishing@user/vanishingideal) (Ping timeout: 276 seconds) |
| 2024-12-19 19:31:25 +0100 | Square2 | (~Square@user/square) (Remote host closed the connection) |
| 2024-12-19 19:31:26 +0100 | OftenFaded | (~OftenFade@user/tisktisk) (Quit: Client closed) |
| 2024-12-19 19:32:31 +0100 | Square | (~Square@user/square) Square |
| 2024-12-19 19:33:27 +0100 | billchenchina | (~billchenc@2a0d:2580:ff0c:1:4a35:c1dc:b9b7:67d8) billchenchina |
| 2024-12-19 19:33:39 +0100 | billchenchina | (~billchenc@2a0d:2580:ff0c:1:4a35:c1dc:b9b7:67d8) (Remote host closed the connection) |
| 2024-12-19 19:36:21 +0100 | wootehfoot | (~wootehfoo@user/wootehfoot) wootehfoot |
| 2024-12-19 19:38:47 +0100 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) peterbecich |
| 2024-12-19 19:44:56 +0100 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 244 seconds) |
| 2024-12-19 19:52:31 +0100 | JuanDaugherty | (~juan@user/JuanDaugherty) (Quit: JuanDaugherty) |
| 2024-12-19 19:54:46 +0100 | wootehfoot | (~wootehfoo@user/wootehfoot) (Read error: Connection reset by peer) |
| 2024-12-19 19:59:09 +0100 | Tuplanolla | (~Tuplanoll@91-159-69-59.elisa-laajakaista.fi) Tuplanolla |
| 2024-12-19 20:00:09 +0100 | briandaed | (~root@user/briandaed) briandaed |
| 2024-12-19 20:02:12 +0100 | fmira | (~user@user/fmira) fmira |
| 2024-12-19 20:03:24 +0100 | fmira | (~user@user/fmira) (Remote host closed the connection) |
| 2024-12-19 20:03:52 +0100 | fmira | (~user@user/fmira) fmira |
| 2024-12-19 20:04:25 +0100 | <__monty__> | I'm looking for kind of the dual to fmap/ap on Maybe, if either argument is Just pick that one. Something like `min <$$> Nothing <**> Just 5 = Just 5`, is that a thing? |
| 2024-12-19 20:05:01 +0100 | <c_wraith> | what if both are Just? |
| 2024-12-19 20:05:59 +0100 | <tomsmeding> | > (<|>) <$> [Nothing, Just 2] <*> [Nothing, Just 3] -- __monty__ |
| 2024-12-19 20:06:01 +0100 | <lambdabot> | [Nothing,Just 3,Just 2,Just 2] |
| 2024-12-19 20:07:52 +0100 | <__monty__> | If both are Just I want to apply the function, `min` in the example. |
| 2024-12-19 20:07:59 +0100 | <tomsmeding> | ah |
| 2024-12-19 20:08:33 +0100 | <tomsmeding> | you can build them from combinators, in generic or less generic ways, but I don't think this particular pattern exists in any of the boot libraries at least |
| 2024-12-19 20:08:48 +0100 | <__monty__> | I've run into this more then once over the past weeks and it feels like it would be a general math thing. |
| 2024-12-19 20:11:11 +0100 | <tomsmeding> | the way in which I've seen it before, I think, is in wanting a "safe foldl1" |
| 2024-12-19 20:11:53 +0100 | <tomsmeding> | i.e. coolSum [1,2,3] = 1 + 2 + 3, and coolSum [1] = 1, but coolSum [] = 0, and in particular coolSum [1] is not 0 + 1 |
| 2024-12-19 20:12:20 +0100 | <tomsmeding> | or perhaps an "optimised foldl'" |
| 2024-12-19 20:14:56 +0100 | homo_ | (~homo@82-128-217-24.bb.dnainternet.fi) |
| 2024-12-19 20:15:05 +0100 | homo_ | (~homo@82-128-217-24.bb.dnainternet.fi) (Changing host) |
| 2024-12-19 20:15:05 +0100 | homo_ | (~homo@user/homo) homo |
| 2024-12-19 20:16:21 +0100 | homo | (~homo@user/homo) (Read error: Connection reset by peer) |
| 2024-12-19 20:16:29 +0100 | <__monty__> | I suppose `(min <$> mA <*> mB) <|> mA <|> mB` is the closest I'll get. |
| 2024-12-19 20:17:05 +0100 | <tomsmeding> | if you use this multiple times and it's a relevant pattern in the domain, I'd write a helper function for it that does precisely what you want |
| 2024-12-19 20:17:26 +0100 | machinedgod | (~machinedg@d108-173-18-100.abhsia.telus.net) machinedgod |
| 2024-12-19 20:17:35 +0100 | <tomsmeding> | applyOn2 min mA mA, perhaps |
| 2024-12-19 20:17:35 +0100 | CrunchyFlakes | (~CrunchyFl@ip1f13e94e.dynamic.kabel-deutschland.de) (Read error: Connection reset by peer) |
| 2024-12-19 20:20:12 +0100 | CrunchyFlakes | (~CrunchyFl@31.19.233.78) |
| 2024-12-19 20:21:47 +0100 | homo_ | homo |
| 2024-12-19 20:23:09 +0100 | <ski> | int-e : elaborate on "unit propagation" and "watched literals" ? |
| 2024-12-19 20:23:38 +0100 | <ski> | tomsmeding : ooh, disjunctive patterns :o .. too bad they can't bind variables yet, but still cool to see :) |
| 2024-12-19 20:23:59 +0100 | tomsmeding | personally feels OrPatterns without binding any variables is only marginally useful |
| 2024-12-19 20:24:11 +0100 | <ski> | int-e : i'd expect forward-chaining "business rules" systems also to have similar stuff, byw |
| 2024-12-19 20:24:12 +0100 | <tomsmeding> | but perhaps that's because of the kind of code I'm writing, I don't really have plain enum data types |
| 2024-12-19 20:24:17 +0100 | <ski> | s/byw/btw/ |
| 2024-12-19 20:25:00 +0100 | <c_wraith> | It seems like the obvious extension is that they can bind variables as long as every clause binds the same names at the same types. |
| 2024-12-19 20:25:18 +0100 | <tomsmeding> | and if the list of alternatives is long, then `foo = \case \n A -> True \n B -> True \n ...` is clearer, I think, than foo (A ; B ; ...) = True |
| 2024-12-19 20:25:22 +0100 | <c_wraith> | Oh, I see. That can interact with type inference, and they didn't want to do that yet. |
| 2024-12-19 20:25:24 +0100 | <tomsmeding> | c_wraith: yes |
| 2024-12-19 20:25:33 +0100 | <int-e> | ski: Hmm. Well, you can view each clause a \/ b \/ c of literals in a SAT problem as a bunch of Horn clauses, -a, -b ==> c etc. Unit propagation is basically Horn inference based on these clauses and literals that have been assigned true. (It stops in a "conflict" if for some variable you assign both its positive and its negative literal to be true) |
| 2024-12-19 20:25:43 +0100 | <tomsmeding> | c_wraith: I get why they didn't want to do it; especially with GADTs it feels very tricky |
| 2024-12-19 20:26:58 +0100 | <int-e> | ski: watched literals are a bit more technical. Basically with "naive evaluation" you'd have to check a clause whenever one of the literals in it becomes true. "watched literals" singles out 2 literals from each clause and waits for one of them to be true before checking the clause; then it either picks a new literal to watch instead or adds the conclusion as a new inference. |
| 2024-12-19 20:27:17 +0100 | <ski> | tomsmeding : <https://rosettacode.org/wiki/Pattern_matching#OCaml> is an example i added (translating to OCaml from other examples), years ago, using disjunctive patterns .. this is an example where being able to bind variables helps avoid some annoying code duplication (the branch body. even if you factor it into a function, you'd still need to pass the bound variables as parameters, in each case) |
| 2024-12-19 20:28:39 +0100 | <tomsmeding> | ski: each of the cases without a right-hand side "fall through" into the next one? |
| 2024-12-19 20:28:46 +0100 | <ski> | "they can bind variables as long as every clause binds the same names at the same types" -- or binds the intersection, if one'd allow "local guards" (one could even do this with view patterns, already, i think ?) |
| 2024-12-19 20:28:47 +0100 | <tomsmeding> | (thinking of C switch-case) |
| 2024-12-19 20:29:53 +0100 | <ski> | > let foo (x,(x ==) -> True) = [x]; foo (x,y) = [x,y] in map foo [(0,0),(1,2)] |
| 2024-12-19 20:29:54 +0100 | <lambdabot> | [[0],[1,2]] |
| 2024-12-19 20:30:01 +0100 | <tomsmeding> | that is indeed cute and a non-trivial use-case, thanks for sharing -- but it does require binding names :) |
| 2024-12-19 20:30:03 +0100 | <int-e> | ski: The reason why people bother with watched literals in this context is that clauses can be very large, having dozens or hundreds of literals. And you have a lot of clauses as well, of course. And SAT solvers spend most of their time doing unit propagation. |
| 2024-12-19 20:30:43 +0100 | <ski> | int-e : negation is problematic, without stratification, though |
| 2024-12-19 20:31:02 +0100 | <ski> | (mm, you mentioned conflict) |
| 2024-12-19 20:32:05 +0100 | <int-e> | ski: Anyway. There's some overlap with the deductive database stuff but I think the above covers the overlap. What SAT solvers do when they encounter a conflict (backtrack, or backjump, and optionally learn a new clause) is specific to SAT solvers. And yeah, it originates in dealing with negation. |
| 2024-12-19 20:32:21 +0100 | <ski> | tomsmeding : "each of the cases without a right-hand side "fall through" into the next one?" -- no, `B, T (R, T (R,a,x,b), y, c), z, d | B, T (R, a, x, T (R,b,y,c)), z, d | ...' is a single disjunctive patten |
| 2024-12-19 20:32:53 +0100 | <ski> | (you can nest disjunctive patterns inside other patterns) |
| 2024-12-19 20:33:08 +0100 | <ski> | also, OCaml tuples do not require outer brackets |
| 2024-12-19 20:34:03 +0100 | <tomsmeding> | ski: so the first '|' introduces a case, the 2nd, 3rd and 4th '|' are disjunctive separators, and the 5th '|' is again a case? |
| 2024-12-19 20:34:13 +0100 | <tomsmeding> | sneaky syntax |
| 2024-12-19 20:34:15 +0100 | <ski> | tomsmeding : iow, there's two different kinds of `|' in that example. (a) ones separating (well, preceding, in my case) the branches; and (b) ones separating the disjuncts/alternatives in a disjunctive pattern |
| 2024-12-19 20:34:15 +0100 | hseg | (~gesh@46.120.21.36) hseg |
| 2024-12-19 20:34:20 +0100 | <ski> | yes |
| 2024-12-19 20:34:31 +0100 | <ski> | giving it the "look" of "fall through" |
| 2024-12-19 20:34:36 +0100 | <tomsmeding> | well, I think my explanation ends up being equivalent anyway :) |
| 2024-12-19 20:34:45 +0100 | <ash3en> | is a new but not innovative library worth publishing a paper and if yes, where? |
| 2024-12-19 20:34:58 +0100 | <hseg> | I forgot to add the sha for an extra-deps in stack, how do I query it from stack? |
| 2024-12-19 20:35:02 +0100 | <ski> | (btw, i have been thinking, some years ago, of a way to do "fall-through" with pattern-matching `case' ..) |
| 2024-12-19 20:35:35 +0100 | <int-e> | ski: does "stratification" correspond to treating each positive and negative literal as its own variable? |
| 2024-12-19 20:36:11 +0100 | <ski> | (imagine `case ... of A x -> f x; B x y -> g x (h x y); C x y z -> g x (i x y z)', but now you want to avoid duplicating the `g x (...)' part of the code) |
| 2024-12-19 20:36:25 +0100 | <tomsmeding> | ash3en: perhaps not a paper, but you could try for a workshop talk if there's something relevant |
| 2024-12-19 20:36:30 +0100 | <int-e> | (i.e. one variable for each possible boolean value) |
| 2024-12-19 20:36:58 +0100 | <ski> | int-e : mm. i see. i think i'd need to look more to understand the why of the watched literals |
| 2024-12-19 20:37:53 +0100 | <ski> | "ends up being equivalent anyway" -- yes (which was why i formatted it that way, apart from it being the easiest way to handle those rather long individual alternatives in the disjunctive pattern) |
| 2024-12-19 20:38:44 +0100 | <ski> | int-e : "stratification" refers to not allowing a predicate to "call itself" (directly or indirectly), inside of a negation |
| 2024-12-19 20:39:12 +0100 | <ski> | (ensuring monotonicity) |
| 2024-12-19 20:39:29 +0100 | <int-e> | ski: Note that the usual explanation for unit propagation is "find clauses in which all but one literal are false and assign true to the last one" and a conflict is a false clause. |
| 2024-12-19 20:40:05 +0100 | <int-e> | ski: So viewing that as an instance of Horn inference is artificial. |
| 2024-12-19 20:41:07 +0100 | <int-e> | But the connection is definitely there :) |
| 2024-12-19 20:41:34 +0100 | <ski> | hm. wondering whether the conflict would be a bit similar deriving the empty clause, with resolution |
| 2024-12-19 20:42:43 +0100 | <ski> | hm, the watched literals sounds kinda like indexing |
| 2024-12-19 20:42:55 +0100 | <ski> | can a clause have multiple watched literals at the same time ? |
| 2024-12-19 20:43:24 +0100 | housemate | (~housemate@149.167.24.31) (Quit: Nothing to see here. I wasn't there. I take IRC seriously.) |
| 2024-12-19 20:43:54 +0100 | <ski> | tomsmeding : "but it does require binding names" -- yes. the point was to show an example where "intersection" would be superior to "require all alternatives to bind the same variables" |
| 2024-12-19 20:44:06 +0100 | <int-e> | ski: It's two. The reason that you need two is that A \/ B encodes both -A -> B and -B -> A. |
| 2024-12-19 20:44:37 +0100 | <int-e> | ski: so you can't get away with only triggering on one of them |
| 2024-12-19 20:44:51 +0100 | <int-e> | while with pure Horn clauses you could |
| 2024-12-19 20:44:53 +0100 | <ski> | (an alternative would be to have an explicit "existential quantification" in patterns, like `forget x in ..x..' *not* binding `x') |
| 2024-12-19 20:46:47 +0100 | <ski> | "and a conflict is a false clause." -- a clause with all literals refuted ? |
| 2024-12-19 20:47:03 +0100 | <int-e> | yeah |
| 2024-12-19 20:47:20 +0100 | <hseg> | nm, just pulled them out of the .lock file |
| 2024-12-19 20:47:24 +0100 | <ski> | "so you can't get away with only triggering on one of them" -- mhm (still not quite following this) |
| 2024-12-19 20:47:32 +0100 | <ski> | conflict causes backtrack (or backjump) ? |
| 2024-12-19 20:47:33 +0100 | <ski> | what is the difference between backtrack and backjump ? |
| 2024-12-19 20:48:20 +0100 | <int-e> | I don't think I can explain backjump on IRC. It's a refinement of backtracking that generally skips more of the search tree. |
| 2024-12-19 20:48:41 +0100 | <ski> | mm |
| 2024-12-19 20:48:56 +0100 | housemate | (~housemate@149.167.24.31) housemate |
| 2024-12-19 20:49:07 +0100 | housemate | (~housemate@149.167.24.31) (Client Quit) |
| 2024-12-19 20:49:09 +0100 | <int-e> | And there *is* a search tree; when unit propagation runs out of inferences without a conflict, you pick a variable that doesn't have a value yet, and tentatively pick one. |
| 2024-12-19 20:49:09 +0100 | <ski> | pruning away branches that are known to only contain failures, or be subsumed by other branches ? |
| 2024-12-19 20:50:02 +0100 | <ski> | yea. i'd imagine you proceed deterministically, comitting to some order, as much as possible, before resorting to backtracking and choice-points |
| 2024-12-19 20:50:03 +0100 | <int-e> | yeah, pruning without discarding solutions |
| 2024-12-19 20:50:15 +0100 | <ski> | (which is what you do in constraint solving) |
| 2024-12-19 20:52:03 +0100 | <ski> | (also stuff like dividing domains in half, adding choice-points, building a binary tree; rather than enumerating elements one by one, which would build a choice-point tree in the form of a linked list. the former may have more potential for discarding whole subtrees, depending on the problem) |
| 2024-12-19 20:52:15 +0100 | vanishingideal | (~vanishing@user/vanishingideal) vanishingideal |
| 2024-12-19 20:54:44 +0100 | michalz | (~michalz@185.246.207.215) (Ping timeout: 264 seconds) |
| 2024-12-19 21:00:00 +0100 | caconym | (~caconym@user/caconym) (Quit: bye) |
| 2024-12-19 21:00:39 +0100 | caconym | (~caconym@user/caconym) caconym |
| 2024-12-19 21:02:57 +0100 | lxsameer | (~lxsameer@Serene/lxsameer) (Ping timeout: 246 seconds) |
| 2024-12-19 21:04:33 +0100 | hseg | (~gesh@46.120.21.36) (Ping timeout: 248 seconds) |
| 2024-12-19 21:08:41 +0100 | michalz | (~michalz@185.246.207.221) |
| 2024-12-19 21:20:16 +0100 | krjst | (~krjst@2604:a880:800:c1::16b:8001) (Ping timeout: 252 seconds) |
| 2024-12-19 21:20:41 +0100 | michalz | (~michalz@185.246.207.221) (Ping timeout: 252 seconds) |
| 2024-12-19 21:21:42 +0100 | michalz | (~michalz@185.246.207.197) |
| 2024-12-19 21:22:55 +0100 | krjst | (~krjst@2604:a880:800:c1::16b:8001) krjst |
| 2024-12-19 21:25:26 +0100 | weary-traveler | (~user@user/user363627) user363627 |
| 2024-12-19 21:28:21 +0100 | prasad | (~Thunderbi@2601:243:c001:3f07::d5) |
| 2024-12-19 21:28:50 +0100 | prasad | (~Thunderbi@2601:243:c001:3f07::d5) () |
| 2024-12-19 21:29:44 +0100 | prasad | (~Thunderbi@2601:243:c001:3f07::d5) |
| 2024-12-19 21:31:53 +0100 | __monty__ | (~toonn@user/toonn) (Ping timeout: 244 seconds) |
| 2024-12-19 21:32:30 +0100 | segfaultfizzbuzz | (~segfaultf@23-93-87-166.dedicated.static.sonic.net) (Remote host closed the connection) |
| 2024-12-19 21:33:13 +0100 | segfaultfizzbuzz | (~segfaultf@23-93-87-166.dedicated.static.sonic.net) segfaultfizzbuzz |
| 2024-12-19 21:34:51 +0100 | poopiedookie | (~poopiedoo@syn-069-206-166-125.res.spectrum.com) |
| 2024-12-19 21:38:23 +0100 | <prasad> | @type mmap |
| 2024-12-19 21:38:24 +0100 | <lambdabot> | error: |
| 2024-12-19 21:38:24 +0100 | <lambdabot> | • Variable not in scope: mmap |
| 2024-12-19 21:38:25 +0100 | <lambdabot> | • Perhaps you meant one of these: |
| 2024-12-19 21:38:42 +0100 | housemate | (~housemate@60.231.48.87) housemate |
| 2024-12-19 21:38:54 +0100 | __monty__ | (~toonn@user/toonn) toonn |
| 2024-12-19 21:41:07 +0100 | housemate_ | (~housemate@60.231.48.87) housemate |
| 2024-12-19 21:41:30 +0100 | housemate | (~housemate@60.231.48.87) (Read error: Connection reset by peer) |
| 2024-12-19 21:41:35 +0100 | <monochrom> | Hot take: Backtrack is just shift within a very recent reset, backjump is just shift within a far away reset. >:) |
| 2024-12-19 21:43:09 +0100 | <monochrom> | "A long long time ago in a reset far far away... CONT WARS" |
| 2024-12-19 21:43:25 +0100 | housemate_ | (~housemate@60.231.48.87) (Remote host closed the connection) |
| 2024-12-19 21:43:38 +0100 | <ski> | choose xs = shift (\c -> concatMap c xs) |
| 2024-12-19 21:46:25 +0100 | <ski> | (`shift' and `reset' also allows you to convert internal iteration (like in `mapM'), to external iteration (like a stream / iterator / generator)) |
| 2024-12-19 21:46:38 +0100 | <monochrom> | :) |
| 2024-12-19 21:46:54 +0100 | <ski> | @hoogle mmap |
| 2024-12-19 21:46:55 +0100 | <lambdabot> | package mmap |
| 2024-12-19 21:46:55 +0100 | <lambdabot> | HaskellWorks.Data.ByteString mmap :: FilePath -> IO ByteString |
| 2024-12-19 21:46:55 +0100 | <lambdabot> | HaskellWorks.Data.Vector.Storable mmap :: Storable a => FilePath -> IO (Vector a) |
| 2024-12-19 21:46:59 +0100 | <ski> | prasad ^ ? |
| 2024-12-19 21:47:03 +0100 | <monochrom> | https://www.vex.net/~trebla/haskell/cont.xhtml#inside-out |
| 2024-12-19 22:02:30 +0100 | housemate | (~housemate@60.231.48.87) housemate |
| 2024-12-19 22:17:30 +0100 | ALpHaBy | (~ALpHaBy@197.25.200.40) |
| 2024-12-19 22:17:51 +0100 | <mreh> | does stack still default to Haskell2010? |
| 2024-12-19 22:18:25 +0100 | <mreh> | or is it an hpack thing? |
| 2024-12-19 22:19:04 +0100 | <tomsmeding> | mreh: this is dictated by the 'default-language' clause in the .cabal file, so probably hpack |
| 2024-12-19 22:19:48 +0100 | <mreh> | tomsmeding: yeah |
| 2024-12-19 22:20:01 +0100 | <mreh> | I say still because GHC has been defaulting to GHC2021 for a while. |
| 2024-12-19 22:20:39 +0100 | <tomsmeding> | mreh: you can add a default-language field to your package.yaml :) |
| 2024-12-19 22:21:49 +0100 | <mreh> | it's not me, some upstream package on hackage, somehow the maintainer is using his packages bypassing the default-language in his cabal files |
| 2024-12-19 22:22:27 +0100 | <mreh> | maybe he's referencing them under `packages:` in his stack.yaml |
| 2024-12-19 22:23:26 +0100 | <tomsmeding> | someone is uploading packages to hackage that don't compile with the .cabal files they're uploaded with? |
| 2024-12-19 22:23:31 +0100 | <tomsmeding> | that's... their problem? :p |
| 2024-12-19 22:23:50 +0100 | <tomsmeding> | then those packages are just broken |
| 2024-12-19 22:26:22 +0100 | <mreh> | maybe he can execute his code inside his head |
| 2024-12-19 22:26:57 +0100 | <ALpHaBy> | where can get free shell or znc ? |
| 2024-12-19 22:28:13 +0100 | <tomsmeding> | at scam companies |
| 2024-12-19 22:28:57 +0100 | <tomsmeding> | if you want a free irc bouncer, try irccloud.com or thelounge.chat |
| 2024-12-19 22:29:21 +0100 | <ALpHaBy> | no for web |
| 2024-12-19 22:29:32 +0100 | <ALpHaBy> | i need one for irc network |
| 2024-12-19 22:30:38 +0100 | <ALpHaBy> | as like channel #ReQuesT in dalnet network |
| 2024-12-19 22:31:02 +0100 | <ALpHaBy> | there evryone can get a free znc |
| 2024-12-19 22:31:55 +0100 | housemate | (~housemate@60.231.48.87) (Remote host closed the connection) |
| 2024-12-19 22:32:04 +0100 | housemate | (~housemate@60.231.48.87) housemate |
| 2024-12-19 22:37:30 +0100 | <mauke> | ALpHaBy: what does that have to do with haskell? |
| 2024-12-19 22:37:42 +0100 | housemate | (~housemate@60.231.48.87) (Ping timeout: 252 seconds) |
| 2024-12-19 22:40:05 +0100 | gmg | (~user@user/gehmehgeh) (Remote host closed the connection) |
| 2024-12-19 22:40:41 +0100 | gmg | (~user@user/gehmehgeh) gehmehgeh |
| 2024-12-19 22:40:41 +0100 | simplystuart | (~simplystu@c-75-75-152-164.hsd1.pa.comcast.net) (Remote host closed the connection) |
| 2024-12-19 22:42:21 +0100 | <ALpHaBy> | mauke i will leave haskell forver becose u are here |
| 2024-12-19 22:42:41 +0100 | <ski> | ALpHaBy : perhaps something like <https://tildeverse.org/>,<http://sdf.org/>,<https://github.com/dimension-sh/> |
| 2024-12-19 22:44:12 +0100 | <int-e> | ©1987-2065 -- amazing they solved the Y2K38 problem already |
| 2024-12-19 22:45:14 +0100 | <int-e> | (from the second link; I feel I might be missing a joke there) |
| 2024-12-19 22:45:43 +0100 | dsrt^ | (dsrt@c-98-242-74-66.hsd1.ga.comcast.net) |
| 2024-12-19 22:47:03 +0100 | <tomsmeding> | some copyright law, perhaps? |
| 2024-12-19 22:47:20 +0100 | tomsmeding | also doesn't get the joke |
| 2024-12-19 22:48:29 +0100 | ski | . o O ( <https://github.com/cwmccabe/pubnixhist> ) |
| 2024-12-19 22:48:57 +0100 | ALpHaBy | (~ALpHaBy@197.25.200.40) () |
| 2024-12-19 22:49:11 +0100 | housemate | (~housemate@ppp203-122-213-191.static.internode.on.net) housemate |
| 2024-12-19 22:49:20 +0100 | Pixi | (~Pixi@user/pixi) Pixi |
| 2024-12-19 22:49:23 +0100 | <int-e> | tomsmeding: Okay one part of the joke is that this is a range of about 2^31 seconds. But who uses 1987 based time stamps? Of course it might be a year of birth. |
| 2024-12-19 22:49:46 +0100 | <int-e> | I can't do math |
| 2024-12-19 22:49:53 +0100 | <geekosaur> | sadly ncoast.org, where I started my journey, is no more |
| 2024-12-19 22:49:56 +0100 | <int-e> | that's 78 years, not 68 |
| 2024-12-19 22:49:58 +0100 | <int-e> | good night |
| 2024-12-19 22:51:58 +0100 | <tomsmeding> | 2065 - 1987 is 0x92b80f00 seconds |
| 2024-12-19 22:52:04 +0100 | <tomsmeding> | according to javascript |
| 2024-12-19 22:53:12 +0100 | <monochrom> | BTW I watched the Y2K movie yesterday haha. |
| 2024-12-19 22:53:23 +0100 | <tomsmeding> | it's all connected |
| 2024-12-19 22:54:27 +0100 | michalz | (~michalz@185.246.207.197) (Remote host closed the connection) |
| 2024-12-19 22:55:24 +0100 | takuan | (~takuan@178-116-218-225.access.telenet.be) (Remote host closed the connection) |
| 2024-12-19 22:57:53 +0100 | fmira | (~user@user/fmira) (Remote host closed the connection) |
| 2024-12-19 22:58:16 +0100 | fmira | (~user@user/fmira) fmira |
| 2024-12-19 23:00:17 +0100 | housemate | (~housemate@ppp203-122-213-191.static.internode.on.net) (Ping timeout: 265 seconds) |
| 2024-12-19 23:00:35 +0100 | <hellwolf> | hmm, how do you easily pattern matching a String prefix? |
| 2024-12-19 23:00:56 +0100 | <hellwolf> | 't':'h':'i':'s':"would be painful" |
| 2024-12-19 23:02:00 +0100 | <monochrom> | I sometimes do that. Other times I use the stripPrefix function. |
| 2024-12-19 23:02:52 +0100 | gorignak | (~gorignak@user/gorignak) gorignak |
| 2024-12-19 23:05:14 +0100 | <tomsmeding> | hellwolf: if you want to be masochistic: https://play.haskell.org/saved/V66qCMa5 |
| 2024-12-19 23:05:31 +0100 | <tomsmeding> | mind the AllowAmbiguousTypes, which is a footgun enabler |
| 2024-12-19 23:06:01 +0100 | <tomsmeding> | perhaps that 'takePrefix' should be called 'stripPrefix' indeed |
| 2024-12-19 23:06:05 +0100 | <hellwolf> | haha, wow. |
| 2024-12-19 23:06:31 +0100 | <tomsmeding> | (the only _inputs_ to a pattern synonym are types, hence... this) |
| 2024-12-19 23:06:40 +0100 | <tomsmeding> | but using ViewPatterns directly you do have inputs |
| 2024-12-19 23:07:07 +0100 | <tomsmeding> | indeed, you can use that 'takePrefix' directly like: foo (takePrefix "this" -> Just s) = putStrLn $ "this and then: " ++ s |
| 2024-12-19 23:07:14 +0100 | <tomsmeding> | which is I think what monochrom was getting at |
| 2024-12-19 23:07:50 +0100 | <hellwolf> | interesting |
| 2024-12-19 23:07:53 +0100 | <monochrom> | pattern guard but yeah. |
| 2024-12-19 23:08:01 +0100 | <tomsmeding> | ah |
| 2024-12-19 23:08:19 +0100 | <hellwolf> | why ViewPatterns is not included in any GHC202 |
| 2024-12-19 23:08:22 +0100 | <hellwolf> | GHC202x |
| 2024-12-19 23:08:37 +0100 | <tomsmeding> | perhaps it was considered too esoteric? |
| 2024-12-19 23:08:57 +0100 | <hellwolf> | perhaps. I barely can write pattern guard properly |
| 2024-12-19 23:09:29 +0100 | <monochrom> | I like pattern guards more. |
| 2024-12-19 23:09:39 +0100 | <tomsmeding> | https://github.com/AccelerateHS/accelerate/blob/02da6161ef143a9886c8bce542cd96029c4f527a/src/Data/… |
| 2024-12-19 23:10:20 +0100 | <c_wraith> | I once did horrible things with stripPrefix and type-level programming |
| 2024-12-19 23:11:06 +0100 | <hellwolf> | folks, all I want is a scanf |
| 2024-12-19 23:11:06 +0100 | hueso_ | (~root@user/hueso) hueso |
| 2024-12-19 23:11:11 +0100 | <hellwolf> | perhaps |
| 2024-12-19 23:11:12 +0100 | hueso | (~root@user/hueso) (Ping timeout: 276 seconds) |
| 2024-12-19 23:11:17 +0100 | <tomsmeding> | import Text.Parsec |
| 2024-12-19 23:11:34 +0100 | <c_wraith> | ugh. use ReadP if you are doing quick and dirty. |
| 2024-12-19 23:11:37 +0100 | <tomsmeding> | okay perhaps a little overpowered for scanf |
| 2024-12-19 23:11:49 +0100 | <c_wraith> | parsec-likes are so painful to refactor. |
| 2024-12-19 23:12:33 +0100 | mreh | (~matthew@host86-146-25-68.range86-146.btcentralplus.com) (Quit: Lost terminal) |
| 2024-12-19 23:13:20 +0100 | <monochrom> | I hate escape codes, so I agree about ReadP. |
| 2024-12-19 23:13:44 +0100 | <c_wraith> | ReadP is surprisingly overlooked for something in base |
| 2024-12-19 23:14:14 +0100 | <Rembane> | Is it Read's competent cousin? |
| 2024-12-19 23:14:18 +0100 | <monochrom> | I used ReadP when I needed a simple parser for a barebone lambda calculus. :) |
| 2024-12-19 23:14:25 +0100 | <monochrom> | Yeah! |
| 2024-12-19 23:14:42 +0100 | <c_wraith> | it's a minimal, but fully-functional parser combinator library for String input |
| 2024-12-19 23:15:39 +0100 | <Rembane> | Sweet! |
| 2024-12-19 23:15:40 +0100 | <c_wraith> | It skips things like error reporting tools. I wouldn't use it for things that have to be user-facing. |
| 2024-12-19 23:16:03 +0100 | <c_wraith> | But when you just want to parse something where it's a flat failure when the input is bad, it's nice. |
| 2024-12-19 23:16:07 +0100 | <monochrom> | Oh I just use it to write Read instances. :) |
| 2024-12-19 23:17:01 +0100 | <ski> | @hackage parsek |
| 2024-12-19 23:17:02 +0100 | <lambdabot> | https://hackage.haskell.org/package/parsek |
| 2024-12-19 23:20:47 +0100 | <geekosaur> | I don't think I've used scanf since, uh, 1988? |
| 2024-12-19 23:21:40 +0100 | <hellwolf> | :D |
| 2024-12-19 23:22:06 +0100 | rynite | (~bwkam@user/rynite) rynite |
| 2024-12-19 23:28:25 +0100 | rynite | (~bwkam@user/rynite) (Quit: WeeChat 4.4.1) |
| 2024-12-19 23:31:34 +0100 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) peterbecich |
| 2024-12-19 23:32:04 +0100 | Logio | (em@kapsi.fi) (Ping timeout: 245 seconds) |
| 2024-12-19 23:32:23 +0100 | Logio | (em@kapsi.fi) Logio |
| 2024-12-19 23:39:26 +0100 | xff0x_ | (~xff0x@2405:6580:b080:900:47af:5bec:f5b4:7548) (Ping timeout: 265 seconds) |
| 2024-12-19 23:40:43 +0100 | byte | (~byte@149.28.222.189) (Killed (gold.libera.chat (Nickname regained by services))) |
| 2024-12-19 23:53:52 +0100 | housemate | (~housemate@ppp203-122-213-191.static.internode.on.net) housemate |
| 2024-12-19 23:56:50 +0100 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 265 seconds) |
| 2024-12-19 23:58:08 +0100 | housemate | (~housemate@ppp203-122-213-191.static.internode.on.net) (Read error: Connection reset by peer) |
| 2024-12-19 23:59:19 +0100 | housemate | (~housemate@ppp203-122-213-191.static.internode.on.net) housemate |
| 2024-12-19 23:59:44 +0100 | housemate | (~housemate@ppp203-122-213-191.static.internode.on.net) (Remote host closed the connection) |