| 2024-09-15 00:00:54 +0200 | takuan | (~takuan@178-116-218-225.access.telenet.be) (Remote host closed the connection) |
| 2024-09-15 00:04:09 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-15 00:08:34 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2024-09-15 00:16:15 +0200 | weary-traveler | (~user@user/user363627) |
| 2024-09-15 00:20:32 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-15 00:25:19 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 264 seconds) |
| 2024-09-15 00:28:19 +0200 | sw4n | (~sw4n@2605:59c0:40f0:9610:559:7713:a305:7d30) (Ping timeout: 264 seconds) |
| 2024-09-15 00:29:17 +0200 | __monty__ | (~toonn@user/toonn) (Quit: leaving) |
| 2024-09-15 00:29:31 +0200 | TheCoffeMaker_ | (~TheCoffeM@186.136.173.70) (Quit: So long and thanks for all the fish) |
| 2024-09-15 00:36:56 +0200 | hgolden_ | (~hgolden@146.70.174.37) (Remote host closed the connection) |
| 2024-09-15 00:38:55 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-15 00:39:04 +0200 | hgolden | (~hgolden@169.150.203.36) |
| 2024-09-15 00:43:44 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 260 seconds) |
| 2024-09-15 00:44:14 +0200 | TheCoffeMaker | (~TheCoffeM@user/thecoffemaker) |
| 2024-09-15 00:50:14 +0200 | john | (~john@2406:5a00:241a:5600:41c4:1903:9759:a97c) (Read error: Connection reset by peer) |
| 2024-09-15 00:51:07 +0200 | john | (~john@2406:5a00:241a:5600:16f:d6b6:8ecf:f15b) |
| 2024-09-15 00:51:07 +0200 | gmg | (~user@user/gehmehgeh) (Quit: Leaving) |
| 2024-09-15 00:56:04 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-15 00:58:48 +0200 | sw4n | (~sw4n@2605:59c0:40f0:9610:559:7713:a305:7d30) |
| 2024-09-15 01:00:39 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 260 seconds) |
| 2024-09-15 01:07:04 +0200 | sw4n | (~sw4n@2605:59c0:40f0:9610:559:7713:a305:7d30) (Ping timeout: 260 seconds) |
| 2024-09-15 01:09:53 +0200 | sw4n | (~sw4n@2605:59c0:40f0:9610:559:7713:a305:7d30) |
| 2024-09-15 01:14:22 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-15 01:14:25 +0200 | sw4n | (~sw4n@2605:59c0:40f0:9610:559:7713:a305:7d30) (Ping timeout: 248 seconds) |
| 2024-09-15 01:19:19 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 260 seconds) |
| 2024-09-15 01:22:12 +0200 | hueso | (~root@user/hueso) (Quit: hueso) |
| 2024-09-15 01:22:36 +0200 | acidjnk | (~acidjnk@p200300d6e72cfb993124db42593adef3.dip0.t-ipconnect.de) (Ping timeout: 246 seconds) |
| 2024-09-15 01:28:28 +0200 | JuanDaugherty | (~juan@user/JuanDaugherty) (Quit: JuanDaugherty) |
| 2024-09-15 01:30:42 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-15 01:32:17 +0200 | hiredman | (~hiredman@frontier1.downey.family) (Quit: Lost terminal) |
| 2024-09-15 01:32:31 +0200 | athan | (~athan@syn-098-153-145-140.biz.spectrum.com) |
| 2024-09-15 01:35:06 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2024-09-15 01:41:27 +0200 | gmg | (~user@user/gehmehgeh) |
| 2024-09-15 01:43:22 +0200 | sw4n | (~sw4n@2605:59c0:40f0:9610:559:7713:a305:7d30) |
| 2024-09-15 01:43:53 +0200 | emmanuelux | (~emmanuelu@user/emmanuelux) |
| 2024-09-15 01:45:51 +0200 | mhatta | (~mhatta@www21123ui.sakura.ne.jp) (Quit: ZNC 1.9.1+deb1 - https://znc.in) |
| 2024-09-15 01:46:23 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-15 01:46:44 +0200 | rao^ | (~rao@c-98-242-74-66.hsd1.ga.comcast.net) (Ping timeout: 260 seconds) |
| 2024-09-15 01:47:51 +0200 | mhatta | (~mhatta@www21123ui.sakura.ne.jp) |
| 2024-09-15 01:50:49 +0200 | sw4n | (~sw4n@2605:59c0:40f0:9610:559:7713:a305:7d30) (Ping timeout: 260 seconds) |
| 2024-09-15 01:51:19 +0200 | Tuplanolla | (~Tuplanoll@91-159-69-59.elisa-laajakaista.fi) (Quit: Leaving.) |
| 2024-09-15 01:51:24 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 260 seconds) |
| 2024-09-15 01:52:42 +0200 | mhatta | (~mhatta@www21123ui.sakura.ne.jp) (Ping timeout: 252 seconds) |
| 2024-09-15 01:52:50 +0200 | mhatta_ | (~mhatta@www21123ui.sakura.ne.jp) |
| 2024-09-15 01:54:51 +0200 | morb | (~morb@pool-108-41-100-120.nycmny.fios.verizon.net) |
| 2024-09-15 01:58:43 +0200 | hueso | (~root@user/hueso) |
| 2024-09-15 01:59:31 +0200 | morb | (~morb@pool-108-41-100-120.nycmny.fios.verizon.net) (Ping timeout: 265 seconds) |
| 2024-09-15 02:02:50 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-15 02:03:38 +0200 | sw4n | (~sw4n@2605:59c0:40f0:9610:559:7713:a305:7d30) |
| 2024-09-15 02:07:44 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 260 seconds) |
| 2024-09-15 02:08:16 +0200 | ChaiTRex | (~ChaiTRex@user/chaitrex) (Ping timeout: 260 seconds) |
| 2024-09-15 02:08:31 +0200 | sw4n | (~sw4n@2605:59c0:40f0:9610:559:7713:a305:7d30) (Ping timeout: 264 seconds) |
| 2024-09-15 02:09:49 +0200 | sw4n | (~sw4n@2605:59c0:40f0:9610:559:7713:a305:7d30) |
| 2024-09-15 02:10:02 +0200 | ChaiTRex | (~ChaiTRex@user/chaitrex) |
| 2024-09-15 02:14:44 +0200 | sw4n | (~sw4n@2605:59c0:40f0:9610:559:7713:a305:7d30) (Ping timeout: 260 seconds) |
| 2024-09-15 02:19:52 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-15 02:22:06 +0200 | troojg | (~troojg@user/troojg) |
| 2024-09-15 02:24:39 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 260 seconds) |
| 2024-09-15 02:29:25 +0200 | hiecaq | (~hiecaq@user/hiecaq) (Quit: ERC 5.5.0.29.1 (IRC client for GNU Emacs 29.4)) |
| 2024-09-15 02:30:10 +0200 | Feuermagier | (~Feuermagi@user/feuermagier) (Ping timeout: 248 seconds) |
| 2024-09-15 02:32:00 +0200 | hiecaq | (~hiecaq@user/hiecaq) |
| 2024-09-15 02:36:44 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-15 02:39:23 +0200 | causal | (~eric@50.35.88.207) |
| 2024-09-15 02:41:00 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 246 seconds) |
| 2024-09-15 02:42:35 +0200 | sw4n | (~sw4n@2605:59c0:40f0:9610:559:7713:a305:7d30) |
| 2024-09-15 02:51:10 +0200 | athan | (~athan@syn-098-153-145-140.biz.spectrum.com) (Quit: Konversation terminated!) |
| 2024-09-15 02:53:15 +0200 | sw4n | (~sw4n@2605:59c0:40f0:9610:559:7713:a305:7d30) (Ping timeout: 246 seconds) |
| 2024-09-15 02:54:38 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-15 02:59:39 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 260 seconds) |
| 2024-09-15 03:03:47 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-15 03:08:10 +0200 | sw4n | (~sw4n@2605:59c0:40f0:9610:559:7713:a305:7d30) |
| 2024-09-15 03:08:59 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 260 seconds) |
| 2024-09-15 03:13:04 +0200 | sw4n | (~sw4n@2605:59c0:40f0:9610:559:7713:a305:7d30) (Ping timeout: 260 seconds) |
| 2024-09-15 03:19:48 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-15 03:24:03 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 246 seconds) |
| 2024-09-15 03:29:00 +0200 | john | synchromesh |
| 2024-09-15 03:29:29 +0200 | sw4n | (~sw4n@2605:59c0:40f0:9610:559:7713:a305:7d30) |
| 2024-09-15 03:33:53 +0200 | sw4n | (~sw4n@2605:59c0:40f0:9610:559:7713:a305:7d30) (Ping timeout: 252 seconds) |
| 2024-09-15 03:36:43 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-15 03:41:06 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 248 seconds) |
| 2024-09-15 03:43:25 +0200 | krei-se | (~krei-se@p57af2718.dip0.t-ipconnect.de) (Ping timeout: 252 seconds) |
| 2024-09-15 03:47:16 +0200 | krei-se | (~krei-se@p57af2362.dip0.t-ipconnect.de) |
| 2024-09-15 03:47:25 +0200 | weary-traveler | (~user@user/user363627) (Remote host closed the connection) |
| 2024-09-15 03:48:00 +0200 | sw4n | (~sw4n@2605:59c0:40f0:9610:559:7713:a305:7d30) |
| 2024-09-15 03:52:38 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-15 03:52:44 +0200 | sw4n | (~sw4n@2605:59c0:40f0:9610:559:7713:a305:7d30) (Ping timeout: 260 seconds) |
| 2024-09-15 03:57:00 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2024-09-15 03:59:58 +0200 | morb | (~morb@pool-108-41-100-120.nycmny.fios.verizon.net) |
| 2024-09-15 04:03:31 +0200 | ZharMeny | (~ZharMeny@user/ZharMeny) (Quit: ERC 5.5.0.29.1 (IRC client for GNU Emacs 29.4)) |
| 2024-09-15 04:05:04 +0200 | op_4 | (~tslil@user/op-4/x-9116473) (Remote host closed the connection) |
| 2024-09-15 04:05:35 +0200 | op_4 | (~tslil@user/op-4/x-9116473) |
| 2024-09-15 04:06:32 +0200 | sw4n | (~sw4n@2605:59c0:40f0:9610:559:7713:a305:7d30) |
| 2024-09-15 04:08:23 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-15 04:10:55 +0200 | sw4n | (~sw4n@2605:59c0:40f0:9610:559:7713:a305:7d30) (Ping timeout: 252 seconds) |
| 2024-09-15 04:11:51 +0200 | <Leary> | thirdofmay: I didn't read the first article closely (it would be too much effort with my weak cat-fu), but I think it's just saying that `iter` takes (endofunctorial) f-algebrae to (monadic / Eilenberg-Moore) `Free f`-algebrae, with an inverse `unIter = \alg -> alg . Op . fmap Pure` making it an isomorphism. This lets your transfer results about (more structured) algebrae over monads to (less structured) algebrae over endofunctors. But this is just a to |
| 2024-09-15 04:11:51 +0200 | <Leary> | ol for the mathematician, of which the free monad is an implementation detail. |
| 2024-09-15 04:12:46 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2024-09-15 04:13:43 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-15 04:14:01 +0200 | caconym9 | caconym |
| 2024-09-15 04:18:38 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2024-09-15 04:25:03 +0200 | sw4n | (~sw4n@2605:59c0:40f0:9610:559:7713:a305:7d30) |
| 2024-09-15 04:29:29 +0200 | sw4n | (~sw4n@2605:59c0:40f0:9610:559:7713:a305:7d30) (Ping timeout: 260 seconds) |
| 2024-09-15 04:30:27 +0200 | weary-traveler | (~user@user/user363627) |
| 2024-09-15 04:31:44 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-15 04:36:09 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 246 seconds) |
| 2024-09-15 04:42:19 +0200 | td_ | (~td@i5387091B.versanet.de) (Ping timeout: 260 seconds) |
| 2024-09-15 04:43:59 +0200 | td_ | (~td@i5387091C.versanet.de) |
| 2024-09-15 04:47:22 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-15 04:51:59 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2024-09-15 04:55:04 +0200 | jathan | (~jathan@69.61.93.38) |
| 2024-09-15 04:55:21 +0200 | spew | (~spew@201.141.99.170) (Quit: spew) |
| 2024-09-15 04:59:03 +0200 | sw4n | (~sw4n@2605:59c0:40f0:9610:559:7713:a305:7d30) |
| 2024-09-15 04:59:03 +0200 | synchromesh | (~john@2406:5a00:241a:5600:16f:d6b6:8ecf:f15b) (Read error: Connection reset by peer) |
| 2024-09-15 04:59:25 +0200 | synchromesh | (~john@2406:5a00:241a:5600:16f:d6b6:8ecf:f15b) |
| 2024-09-15 05:03:24 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-15 05:03:54 +0200 | sw4n | (~sw4n@2605:59c0:40f0:9610:559:7713:a305:7d30) (Ping timeout: 260 seconds) |
| 2024-09-15 05:06:52 +0200 | sw4n | (~sw4n@2605:59c0:40f0:9610:559:7713:a305:7d30) |
| 2024-09-15 05:07:59 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 260 seconds) |
| 2024-09-15 05:12:06 +0200 | sw4n | (~sw4n@2605:59c0:40f0:9610:559:7713:a305:7d30) (Ping timeout: 276 seconds) |
| 2024-09-15 05:13:41 +0200 | morb | (~morb@pool-108-41-100-120.nycmny.fios.verizon.net) (Remote host closed the connection) |
| 2024-09-15 05:18:36 +0200 | ridcully | (~ridcully@p508ac2b4.dip0.t-ipconnect.de) (Ping timeout: 276 seconds) |
| 2024-09-15 05:19:19 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-15 05:24:19 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 260 seconds) |
| 2024-09-15 05:31:41 +0200 | ridcully | (~ridcully@p57b528bc.dip0.t-ipconnect.de) |
| 2024-09-15 05:32:40 +0200 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) (Ping timeout: 265 seconds) |
| 2024-09-15 05:33:07 +0200 | telser | (~quassel@user/telser) |
| 2024-09-15 05:34:13 +0200 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) |
| 2024-09-15 05:35:23 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-15 05:35:31 +0200 | telser | (~quassel@user/telser) (Client Quit) |
| 2024-09-15 05:40:01 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2024-09-15 05:40:23 +0200 | sw4n | (~sw4n@2605:59c0:40f0:9610:559:7713:a305:7d30) |
| 2024-09-15 05:44:44 +0200 | sw4n | (~sw4n@2605:59c0:40f0:9610:559:7713:a305:7d30) (Ping timeout: 260 seconds) |
| 2024-09-15 05:50:35 +0200 | telser | (~quassel@user/telser) |
| 2024-09-15 05:51:46 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-15 05:52:30 +0200 | troojg | (~troojg@user/troojg) (Remote host closed the connection) |
| 2024-09-15 05:56:10 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2024-09-15 05:58:54 +0200 | sw4n | (~sw4n@2605:59c0:40f0:9610:559:7713:a305:7d30) |
| 2024-09-15 06:03:18 +0200 | sw4n | (~sw4n@2605:59c0:40f0:9610:559:7713:a305:7d30) (Ping timeout: 246 seconds) |
| 2024-09-15 06:08:22 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-15 06:13:02 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2024-09-15 06:14:44 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-15 06:17:30 +0200 | sw4n | (~sw4n@2605:59c0:40f0:9610:559:7713:a305:7d30) |
| 2024-09-15 06:19:44 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 260 seconds) |
| 2024-09-15 06:22:04 +0200 | sw4n | (~sw4n@2605:59c0:40f0:9610:559:7713:a305:7d30) (Ping timeout: 260 seconds) |
| 2024-09-15 06:28:56 +0200 | JuanDaugherty | (~juan@user/JuanDaugherty) |
| 2024-09-15 06:30:36 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-15 06:33:27 +0200 | pavonia | (~user@user/siracusa) |
| 2024-09-15 06:35:02 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2024-09-15 06:42:17 +0200 | sw4n | (~sw4n@2605:59c0:40f0:9610:559:7713:a305:7d30) |
| 2024-09-15 06:46:41 +0200 | sw4n | (~sw4n@2605:59c0:40f0:9610:559:7713:a305:7d30) (Ping timeout: 248 seconds) |
| 2024-09-15 06:47:18 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-15 06:48:36 +0200 | naxx | (~brandt@177.191-pool-nas4-sc.sccoast.net) (Quit: WeeChat 4.4.2) |
| 2024-09-15 06:51:54 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2024-09-15 07:01:53 +0200 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) |
| 2024-09-15 07:04:14 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-15 07:08:51 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 265 seconds) |
| 2024-09-15 07:15:23 +0200 | JuanDaugherty | (~juan@user/JuanDaugherty) (Quit: JuanDaugherty) |
| 2024-09-15 07:19:17 +0200 | sw4n | (~sw4n@2605:59c0:40f0:9610:559:7713:a305:7d30) |
| 2024-09-15 07:19:47 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-15 07:19:58 +0200 | euphores | (~SASL_euph@user/euphores) (Ping timeout: 265 seconds) |
| 2024-09-15 07:23:54 +0200 | sw4n | (~sw4n@2605:59c0:40f0:9610:559:7713:a305:7d30) (Ping timeout: 260 seconds) |
| 2024-09-15 07:24:09 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 246 seconds) |
| 2024-09-15 07:25:58 +0200 | euphores | (~SASL_euph@user/euphores) |
| 2024-09-15 07:27:15 +0200 | emaczen | (~user@user/emaczen) |
| 2024-09-15 07:27:56 +0200 | sw4n | (~sw4n@2605:59c0:40f0:9610:559:7713:a305:7d30) |
| 2024-09-15 07:30:18 +0200 | euphores | (~SASL_euph@user/euphores) (Client Quit) |
| 2024-09-15 07:37:21 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-15 07:37:47 +0200 | euphores | (~SASL_euph@user/euphores) |
| 2024-09-15 07:42:07 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 264 seconds) |
| 2024-09-15 07:46:08 +0200 | sourcetarius_ | (~sourcetar@user/sourcetarius) (Quit: nyaa~) |
| 2024-09-15 07:53:51 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-15 07:58:54 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 260 seconds) |
| 2024-09-15 07:59:48 +0200 | sw4n | (~sw4n@2605:59c0:40f0:9610:559:7713:a305:7d30) (Ping timeout: 276 seconds) |
| 2024-09-15 08:06:41 +0200 | emaczen | (~user@user/emaczen) (Ping timeout: 248 seconds) |
| 2024-09-15 08:09:27 +0200 | czy | (~user@host86-151-168-160.range86-151.btcentralplus.com) |
| 2024-09-15 08:11:19 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-15 08:11:30 +0200 | misterfish | (~misterfis@84.53.85.146) |
| 2024-09-15 08:13:56 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2024-09-15 08:16:02 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 265 seconds) |
| 2024-09-15 08:28:28 +0200 | sw4n | (~sw4n@2605:59c0:40f0:9610:559:7713:a305:7d30) |
| 2024-09-15 08:29:11 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-15 08:33:19 +0200 | sw4n | (~sw4n@2605:59c0:40f0:9610:559:7713:a305:7d30) (Ping timeout: 260 seconds) |
| 2024-09-15 08:33:50 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2024-09-15 08:44:50 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-15 08:49:39 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 260 seconds) |
| 2024-09-15 08:53:31 +0200 | econo_ | (uid147250@id-147250.tinside.irccloud.com) (Quit: Connection closed for inactivity) |
| 2024-09-15 08:54:44 +0200 | misterfish | (~misterfis@84.53.85.146) (Ping timeout: 252 seconds) |
| 2024-09-15 08:58:09 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2024-09-15 09:00:02 +0200 | caconym | (~caconym@user/caconym) (Quit: bye) |
| 2024-09-15 09:00:07 +0200 | tt123109783243 | (~tt1231@2603:6010:8700:4a81:219f:50d3:618a:a6ee) (Quit: The Lounge - https://thelounge.chat) |
| 2024-09-15 09:00:37 +0200 | caconym | (~caconym@user/caconym) |
| 2024-09-15 09:01:44 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-15 09:03:36 +0200 | tt123109783243 | (~tt1231@2603:6010:8700:4a81:219f:50d3:618a:a6ee) |
| 2024-09-15 09:06:01 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2024-09-15 09:06:29 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 248 seconds) |
| 2024-09-15 09:06:43 +0200 | takuan | (~takuan@178-116-218-225.access.telenet.be) |
| 2024-09-15 09:07:34 +0200 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 252 seconds) |
| 2024-09-15 09:08:03 +0200 | gmg | (~user@user/gehmehgeh) (Quit: Leaving) |
| 2024-09-15 09:14:46 +0200 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) |
| 2024-09-15 09:17:46 +0200 | gmg | (~user@user/gehmehgeh) |
| 2024-09-15 09:18:44 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-15 09:23:20 +0200 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 252 seconds) |
| 2024-09-15 09:23:29 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 260 seconds) |
| 2024-09-15 09:25:46 +0200 | Squared | (~Square@user/square) |
| 2024-09-15 09:28:20 +0200 | benjaminl | (~benjaminl@user/benjaminl) (Read error: Connection reset by peer) |
| 2024-09-15 09:28:35 +0200 | benjaminl | (~benjaminl@user/benjaminl) |
| 2024-09-15 09:29:06 +0200 | oneeyedalien | (~oneeyedal@user/oneeyedalien) |
| 2024-09-15 09:29:07 +0200 | oneeyedalien | (~oneeyedal@user/oneeyedalien) (Max SendQ exceeded) |
| 2024-09-15 09:29:33 +0200 | oneeyedalien | (~oneeyedal@user/oneeyedalien) |
| 2024-09-15 09:34:49 +0200 | target_i | (~target_i@user/target-i/x-6023099) |
| 2024-09-15 09:34:52 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-15 09:39:49 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 260 seconds) |
| 2024-09-15 09:41:58 +0200 | sw4n | (~sw4n@2605:59c0:40f0:9610:559:7713:a305:7d30) |
| 2024-09-15 09:46:25 +0200 | sw4n | (~sw4n@2605:59c0:40f0:9610:559:7713:a305:7d30) (Ping timeout: 248 seconds) |
| 2024-09-15 09:50:35 +0200 | acidjnk | (~acidjnk@p200300d6e72cfb77305c26d382fbfdca.dip0.t-ipconnect.de) |
| 2024-09-15 09:53:09 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-15 09:54:58 +0200 | mreh | (~matthew@host86-160-168-12.range86-160.btcentralplus.com) |
| 2024-09-15 09:57:48 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2024-09-15 10:00:27 +0200 | sw4n | (~sw4n@2605:59c0:40f0:9610:559:7713:a305:7d30) |
| 2024-09-15 10:01:05 +0200 | YuutaW | (~YuutaW@mail.yuuta.moe) |
| 2024-09-15 10:04:41 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-15 10:04:54 +0200 | sw4n | (~sw4n@2605:59c0:40f0:9610:559:7713:a305:7d30) (Ping timeout: 260 seconds) |
| 2024-09-15 10:08:20 +0200 | weary-traveler | (~user@user/user363627) (Remote host closed the connection) |
| 2024-09-15 10:15:25 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 265 seconds) |
| 2024-09-15 10:16:11 +0200 | oneeyedalien | (~oneeyedal@user/oneeyedalien) (Quit: Leaving) |
| 2024-09-15 10:16:34 +0200 | Pozyomka | (~pyon@user/pyon) (Quit: WeeChat 4.4.1) |
| 2024-09-15 10:28:10 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-15 10:32:54 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 260 seconds) |
| 2024-09-15 10:33:59 +0200 | sw4n | (~sw4n@2605:59c0:40f0:9610:559:7713:a305:7d30) |
| 2024-09-15 10:39:06 +0200 | youthlic | (~Thunderbi@user/youthlic) (Remote host closed the connection) |
| 2024-09-15 10:41:13 +0200 | sw4n | (~sw4n@2605:59c0:40f0:9610:559:7713:a305:7d30) (Ping timeout: 245 seconds) |
| 2024-09-15 10:41:40 +0200 | youthlic | (~Thunderbi@user/youthlic) |
| 2024-09-15 10:44:17 +0200 | ash3en | (~Thunderbi@2a01:c23:8d69:4600:ccd4:88c0:9e3f:3453) |
| 2024-09-15 10:45:26 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-15 10:48:52 +0200 | ash3en | (~Thunderbi@2a01:c23:8d69:4600:ccd4:88c0:9e3f:3453) (Client Quit) |
| 2024-09-15 10:49:52 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2024-09-15 11:00:18 +0200 | Tuplanolla | (~Tuplanoll@91-159-69-59.elisa-laajakaista.fi) |
| 2024-09-15 11:00:56 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-15 11:01:27 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2024-09-15 11:01:29 +0200 | wootehfoot | (~wootehfoo@user/wootehfoot) |
| 2024-09-15 11:02:10 +0200 | causal | (~eric@50.35.88.207) (Quit: WeeChat 4.3.1) |
| 2024-09-15 11:05:42 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 276 seconds) |
| 2024-09-15 11:10:29 +0200 | sw4n | (~sw4n@2605:59c0:40f0:9610:559:7713:a305:7d30) |
| 2024-09-15 11:11:48 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2024-09-15 11:16:46 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-15 11:21:46 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2024-09-15 11:26:57 +0200 | tzh | (~tzh@c-76-115-131-146.hsd1.or.comcast.net) (Quit: zzz) |
| 2024-09-15 11:35:02 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-15 11:38:14 +0200 | sw4n | (~sw4n@2605:59c0:40f0:9610:559:7713:a305:7d30) (Ping timeout: 260 seconds) |
| 2024-09-15 11:39:44 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2024-09-15 11:48:55 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Read error: Connection reset by peer) |
| 2024-09-15 11:49:47 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) |
| 2024-09-15 11:51:11 +0200 | sw4n | (~sw4n@2605:59c0:40f0:9610:559:7713:a305:7d30) |
| 2024-09-15 11:51:20 +0200 | flounders | (~flounders@2607:fb91:f40:c71f:f5c9:7500:92f8:5ba9) |
| 2024-09-15 11:51:50 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-15 11:52:07 +0200 | CiaoSen | (~Jura@2a05:5800:244:d800:ca4b:d6ff:fec1:99da) |
| 2024-09-15 11:55:44 +0200 | sw4n | (~sw4n@2605:59c0:40f0:9610:559:7713:a305:7d30) (Ping timeout: 260 seconds) |
| 2024-09-15 11:56:06 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 246 seconds) |
| 2024-09-15 12:02:25 +0200 | CiaoSen | (~Jura@2a05:5800:244:d800:ca4b:d6ff:fec1:99da) (Ping timeout: 248 seconds) |
| 2024-09-15 12:05:42 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-15 12:10:23 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 245 seconds) |
| 2024-09-15 12:17:31 +0200 | Piedro | (~Piedro@84.15.223.154) |
| 2024-09-15 12:18:58 +0200 | __monty__ | (~toonn@user/toonn) |
| 2024-09-15 12:19:47 +0200 | raym | (~ray@user/raym) (Ping timeout: 255 seconds) |
| 2024-09-15 12:21:52 +0200 | <fr33domlover> | o/ Is there a constraint that is the opposite of ~ ? e.g. (a !~ b) that is similarly inferred when a and b *aren't* the same type? |
| 2024-09-15 12:22:17 +0200 | <fr33domlover> | I'd like to use such a constraint in a typeclass instance |
| 2024-09-15 12:22:42 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-15 12:22:59 +0200 | <Leary> | Nope. |
| 2024-09-15 12:24:37 +0200 | lxsameer | (~lxsameer@Serene/lxsameer) |
| 2024-09-15 12:25:25 +0200 | <tomsmeding> | fr33domlover: haskell is based on the invariant that knowing _more_ information can only make your program more defined |
| 2024-09-15 12:25:58 +0200 | <fr33domlover> | There's (==) from Data.Type.Equality, but I guess (a == b ~ False) isn't inferred in the same way? |
| 2024-09-15 12:26:10 +0200 | <tomsmeding> | e.g. knowing more type equalities will not make your program cease to type-check. Having more typeclass instances in scope will not make instance resolution fail. |
| 2024-09-15 12:27:05 +0200 | <tomsmeding> | passing a non-bottom value to a function will not make that function return more bottoms than if you pass it 'undefined'. (caveat: by catching exceptions in IO you can subvert this) |
| 2024-09-15 12:27:24 +0200 | czy | (~user@host86-151-168-160.range86-151.btcentralplus.com) (Ping timeout: 252 seconds) |
| 2024-09-15 12:27:29 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 248 seconds) |
| 2024-09-15 12:28:17 +0200 | <tomsmeding> | fr33domlover: hm, I guess that works |
| 2024-09-15 12:28:27 +0200 | <tomsmeding> | but you won't be able to case-analyse with this |
| 2024-09-15 12:28:51 +0200 | <tomsmeding> | or maybe you can |
| 2024-09-15 12:28:53 +0200 | <tomsmeding> | hm |
| 2024-09-15 12:29:31 +0200 | <tomsmeding> | fr33domlover: if (==) is enough for your usecase, it should work :p |
| 2024-09-15 12:30:14 +0200 | <tomsmeding> | a ~ b will imply a == b ~ True, but a == b ~ True doesn't imply a ~ b, and a == b ~ False also doesn't imply NOT(a ~ b) |
| 2024-09-15 12:31:02 +0200 | <tomsmeding> | in that sense it lives "outside" the core type system |
| 2024-09-15 12:31:33 +0200 | <fr33domlover> | tomsmeding: But are there cases where (a ~ b) and (a == b) don't agree? |
| 2024-09-15 12:31:49 +0200 | <tomsmeding> | no, they're just not bidirectionally inferrable |
| 2024-09-15 12:31:56 +0200 | <tomsmeding> | ~ is magic, == is not |
| 2024-09-15 12:32:08 +0200 | <tomsmeding> | hence ~ will imply ==, but == does not impart actual information to the compiler |
| 2024-09-15 12:32:21 +0200 | <tomsmeding> | it's just some arbitrary type family that happens to evaluate to True or False |
| 2024-09-15 12:32:49 +0200 | <fr33domlover> | I'll try my code with == and see if it generates instances the way I intend ^_^ |
| 2024-09-15 12:33:16 +0200 | <tomsmeding> | e.g. the following doesn't typecheck: foo :: a == b ~ True => a -> b ; foo x = x |
| 2024-09-15 12:33:58 +0200 | <tomsmeding> | (with parens around the (a == b)) |
| 2024-09-15 12:39:29 +0200 | sw4n | (~sw4n@2605:59c0:40f0:9610:559:7713:a305:7d30) |
| 2024-09-15 12:39:32 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-15 12:44:30 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 276 seconds) |
| 2024-09-15 12:44:30 +0200 | sw4n | (~sw4n@2605:59c0:40f0:9610:559:7713:a305:7d30) (Ping timeout: 276 seconds) |
| 2024-09-15 12:47:57 +0200 | ZharMeny | (~ZharMeny@user/ZharMeny) |
| 2024-09-15 12:48:37 +0200 | <ski> | "knowing _more_ information can only make your program more defined" -- sounds somehow related to "steadfastness", now that i think about it, hmm .. |
| 2024-09-15 12:48:54 +0200 | Piedro | (~Piedro@84.15.223.154) (Remote host closed the connection) |
| 2024-09-15 12:49:02 +0200 | <tomsmeding> | I was thinking about "monotonicity" but I know too little about the actual theory so I didn't want to use the word incorrectly |
| 2024-09-15 12:49:26 +0200 | <tomsmeding> | (and it seems I wasn't even quite correct because (==) does allow a limited form of antimonotonicity) |
| 2024-09-15 12:49:59 +0200 | <tomsmeding> | (limited because inference only goes one way) |
| 2024-09-15 12:50:35 +0200 | <ski> | a predicate in Prolog is steadfast, if providing more information to a call of it cannot make it produce more solutions, or less instantiated (/known( ones, but only make it produce less solutions, or more instantiated ones |
| 2024-09-15 12:51:01 +0200 | <tomsmeding> | that sounds very related yes |
| 2024-09-15 12:51:18 +0200 | <tomsmeding> | does using ~ (not) in prolog break that in general? |
| 2024-09-15 12:51:21 +0200 | rvalue | (~rvalue@user/rvalue) (Read error: Connection reset by peer) |
| 2024-09-15 12:51:53 +0200 | rvalue | (~rvalue@user/rvalue) |
| 2024-09-15 12:52:25 +0200 | <ski> | while, your property sounds more like : adding more defining clauses (or generalizing existing ones) to predicates in pure Prolog (without cut, negation-as-failure) cannot make queries produce less solutions (or more instantiated ones), only the other way around |
| 2024-09-15 12:52:42 +0200 | <ski> | yes, negation-by-failure breaks this |
| 2024-09-15 12:52:56 +0200 | <ski> | (and cut, which is how negation-as-failure is implemented) |
| 2024-09-15 12:53:20 +0200 | <tomsmeding> | if you see type class inference as a very weak logic programming language, my property sounds like steadfastness, I think |
| 2024-09-15 12:53:28 +0200 | <tomsmeding> | ah no I see |
| 2024-09-15 12:53:30 +0200 | <tomsmeding> | you're right |
| 2024-09-15 12:53:43 +0200 | <tomsmeding> | not quite the same |
| 2024-09-15 12:54:25 +0200 | <ski> | basically, non-steadfastness means that commutativity of conjunction breaks. `p(X,Y),X = foo' might not be equivalent to `X = foo,p(X,Y)' (providing more information about `X' before calling `p/2') |
| 2024-09-15 12:55:01 +0200 | <tomsmeding> | oof the lack of space after that separating `,` broke my brain for a bit |
| 2024-09-15 12:55:25 +0200 | <ski> | steadfastness is about calling a specific predicate. while i think what you're talking about seems more related to adding to definition of a predicate |
| 2024-09-15 12:55:45 +0200 | <ski> | but they seem to be related |
| 2024-09-15 12:55:51 +0200 | <tomsmeding> | indeed, adding new predicates or adding more clauses to an existing predicate |
| 2024-09-15 12:56:09 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-15 12:56:18 +0200 | <tomsmeding> | (which I guess is the same thing, if all potential predicates already exist, just with zero clauses) |
| 2024-09-15 12:56:38 +0200 | <ski> | one's about conjunctively adding stuff to goals/queries. the other's about conjunctively adding stuff to clauses. goals and clauses are "opposite". clauses are assumed, goals are to be proved |
| 2024-09-15 12:57:05 +0200 | <ski> | yea |
| 2024-09-15 12:57:57 +0200 | <ski> | (in constraint logic terminology, there's a "duality" between "tell" and "ask") |
| 2024-09-15 13:01:04 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 260 seconds) |
| 2024-09-15 13:03:54 +0200 | mrmr155334346318 | (~mrmr@user/mrmr) (Quit: Bye, See ya later!) |
| 2024-09-15 13:04:12 +0200 | <ski> | here's an example of a non-steadfast predicate definition |
| 2024-09-15 13:04:20 +0200 | <ski> | max(X,Y,X) :- X >= Y,!. |
| 2024-09-15 13:04:29 +0200 | <ski> | max(_,Y,Y). |
| 2024-09-15 13:05:34 +0200 | Guest|97 | (~Guest|97@73.220.6.51.dyn.plus.net) |
| 2024-09-15 13:05:48 +0200 | <ski> | the intention is to compare the first two parameters `X', and `Y'. if `X' is the greater, then set the result parameter to `X', *otherwise* set it to `Y' (the `!' causes lack of backtracking to the second predicate, if `X >= Y' succeeds, implementing the "otherwise" part. without it, we wouldn't have committed to the first clause, and so the query `?- max(3,2,Z).' would then have had two solutions) |
| 2024-09-15 13:05:50 +0200 | Guest|97 | (~Guest|97@73.220.6.51.dyn.plus.net) (Client Quit) |
| 2024-09-15 13:06:32 +0200 | <ski> | however, this can be broken by providing the third parameter upfront, in a query like `?- max(3,2,2).' (equivalent to `?- Z = 2,max(3,2,Z).'), which doesn't even try `3 >= 2' because the third parameter doesn't unify with the first (call doesn't match with clause head `max(X,Y,X)'), and so goes to the fallback/catch-all clause, and (incorrectly) *succeeds* there (because we wanted to avoid a second |
| 2024-09-15 13:06:38 +0200 | <ski> | comparision check, `X =< Y') ! while, otoh, `?- max(3,2,Z),Z = 2.' (correctly) fails |
| 2024-09-15 13:07:47 +0200 | <ski> | the correct way to do this, is to either bite the bullet, and duplicate the check (well, i guess it's better to use `X < Y' rather than `X =< Y', to avoid duplicate solutions, though that's only a performance issue, not a correctness issue) |
| 2024-09-15 13:07:59 +0200 | <ski> | max(X,Y,X) :- X >= Y. |
| 2024-09-15 13:08:06 +0200 | <ski> | max(X,Y,Y) :- X < Y. |
| 2024-09-15 13:08:32 +0200 | <ski> | or, to correctly use the cut (`!'), you have to put the "output unification" *after* the cut |
| 2024-09-15 13:08:48 +0200 | <ski> | max(X,Y,Z) :- X >= Y,!,Z = X. |
| 2024-09-15 13:08:55 +0200 | <ski> | max(_,Y,Y). |
| 2024-09-15 13:09:03 +0200 | <ski> | which is equivalent to |
| 2024-09-15 13:09:27 +0200 | <ski> | max(X,Y,Z) :- ( X >= Y -> Z = X ; Z = Y ). % using a conditional |
| 2024-09-15 13:10:39 +0200 | <ski> | the main point is that if you use cut (or negation-by-failure), it's very easy to end up with illogical (non-steadfast) predicates, if you're not careful |
| 2024-09-15 13:11:15 +0200 | <tomsmeding> | interesting |
| 2024-09-15 13:11:47 +0200 | <tomsmeding> | reminds me of the trick in haskell where if you want to provide an instance that requires certain type arguments to be identical, you should put that equality in the context of the instance, not make the actual syntactic arguments the same |
| 2024-09-15 13:12:05 +0200 | <tomsmeding> | e.g. writing `instance (n ~ n') => IsLabel n (SSymbol n')` |
| 2024-09-15 13:12:14 +0200 | <tomsmeding> | not sure whether it just looks similar or actually is related |
| 2024-09-15 13:12:36 +0200 | <tomsmeding> | there is a "matching -> cut (instance selection) -> output unification" sequence, though |
| 2024-09-15 13:13:05 +0200 | sw4n | (~sw4n@2605:59c0:40f0:9610:559:7713:a305:7d30) |
| 2024-09-15 13:13:24 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-15 13:13:40 +0200 | <ski> | yea, hmm |
| 2024-09-15 13:15:36 +0200 | synchromesh | (~john@2406:5a00:241a:5600:16f:d6b6:8ecf:f15b) (Read error: Connection reset by peer) |
| 2024-09-15 13:17:05 +0200 | synchromesh | (~john@2406:5a00:241a:5600:16f:d6b6:8ecf:f15b) |
| 2024-09-15 13:17:20 +0200 | <ski> | well, i suppose the type constructors, and the shared (non-linear) type variables in parameters of the head of a type class can be viewed as "inputs" (will be considered upon instance resolution selecting instance rules. if there's no conclusive input information, selection will just be stalled/delayed/suspended for that "call"). while the calls and equalities in the context can be viewed as "outputs" of |
| 2024-09-15 13:17:26 +0200 | <ski> | that instance rule |
| 2024-09-15 13:17:50 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 255 seconds) |
| 2024-09-15 13:17:59 +0200 | sw4n | (~sw4n@2605:59c0:40f0:9610:559:7713:a305:7d30) (Ping timeout: 260 seconds) |
| 2024-09-15 13:19:07 +0200 | <lxsameer> | If you're an Emacs user, could you please share your haskell setup with me? |
| 2024-09-15 13:30:59 +0200 | mrmr155334346318 | (~mrmr@user/mrmr) |
| 2024-09-15 13:31:37 +0200 | sw4n | (~sw4n@2605:59c0:40f0:9610:559:7713:a305:7d30) |
| 2024-09-15 13:31:40 +0200 | <jackdk> | I just use dante to run ghcid out of flycheck |
| 2024-09-15 13:31:45 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-15 13:36:29 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 265 seconds) |
| 2024-09-15 13:42:26 +0200 | Inst_ | (~Inst@user/Inst) |
| 2024-09-15 13:42:34 +0200 | Inst | (~Inst@user/Inst) (Remote host closed the connection) |
| 2024-09-15 13:43:25 +0200 | Inst_ | (~Inst@user/Inst) (Remote host closed the connection) |
| 2024-09-15 13:44:03 +0200 | <lxsameer> | jackdk: no haskell-mode? |
| 2024-09-15 13:44:23 +0200 | Inst_ | (~Inst@user/Inst) |
| 2024-09-15 13:44:55 +0200 | Inst_ | (~Inst@user/Inst) (Remote host closed the connection) |
| 2024-09-15 13:45:43 +0200 | <jackdk> | Oh yeah sure for syntax highlighting but I never got around to setting up fancy keybinds or lsp-mode or eglot or anything |
| 2024-09-15 13:47:20 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-15 13:47:53 +0200 | sw4n | (~sw4n@2605:59c0:40f0:9610:559:7713:a305:7d30) (Ping timeout: 245 seconds) |
| 2024-09-15 13:50:51 +0200 | sourcetarius | (~sourcetar@user/sourcetarius) |
| 2024-09-15 13:51:44 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2024-09-15 13:58:45 +0200 | morb | (~morb@pool-108-41-100-120.nycmny.fios.verizon.net) |
| 2024-09-15 14:00:08 +0200 | <lxsameer> | jackdk: I'm using eglot, never tried dante, the thing that pisses off the most about my setup is that, if I have a compilation issue in my code, my setup kinda would be useless, no type in the echo area, or no eldoc stuff until i fixed the issue. have you experinced a similar thing with Dante? |
| 2024-09-15 14:01:27 +0200 | <jackdk> | I don't think I use any of those things. I get red squigglies under compilation errors and that has been enough for me |
| 2024-09-15 14:01:48 +0200 | Sgeo | (~Sgeo@user/sgeo) (Read error: Connection reset by peer) |
| 2024-09-15 14:02:45 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-15 14:03:01 +0200 | <lxsameer> | jackdk: cool, one last question, how do you get more info about a function, the type signature or the docmuntation and such? i mean as part of your workflow |
| 2024-09-15 14:03:09 +0200 | morb | (~morb@pool-108-41-100-120.nycmny.fios.verizon.net) (Ping timeout: 246 seconds) |
| 2024-09-15 14:06:42 +0200 | JuanDaugherty | (~juan@user/JuanDaugherty) |
| 2024-09-15 14:07:03 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 245 seconds) |
| 2024-09-15 14:12:55 +0200 | <Athas> | Does Data.List not have a function that removes the first element that satisfies some predicate? I cannot seem to find it. |
| 2024-09-15 14:18:25 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-15 14:18:53 +0200 | <Leary> | Athas: I doubt it. Use `break`. |
| 2024-09-15 14:19:39 +0200 | michalz | (~michalz@185.246.207.203) |
| 2024-09-15 14:19:40 +0200 | <Athas> | Ugh. I'll rather just write the recursive function myself. |
| 2024-09-15 14:19:40 +0200 | <mauke> | deleteBy |
| 2024-09-15 14:19:55 +0200 | <Athas> | mauke: doesn't work; it requires the needle and haystack elements are the same type. |
| 2024-09-15 14:20:12 +0200 | <Athas> | Although interestingly, this seems like an artificial restriction imposed by the type signature. |
| 2024-09-15 14:20:33 +0200 | <mauke> | :t \p -> deleteBy (const p) undefined |
| 2024-09-15 14:20:34 +0200 | <lambdabot> | (b -> Bool) -> [b] -> [b] |
| 2024-09-15 14:21:20 +0200 | <Athas> | Ha! Clever, but horrifying. |
| 2024-09-15 14:23:31 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 264 seconds) |
| 2024-09-15 14:31:09 +0200 | <Leary> | Definitely blame that one on whoever wrote the function so silly in the first place. |
| 2024-09-15 14:35:38 +0200 | sw4n | (~sw4n@2605:59c0:40f0:9610:559:7713:a305:7d30) |
| 2024-09-15 14:36:09 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-15 14:40:36 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 246 seconds) |
| 2024-09-15 14:40:45 +0200 | <Athas> | I'll send a mail pronto to Simon complaining that his language is bad. |
| 2024-09-15 14:40:51 +0200 | sw4n | (~sw4n@2605:59c0:40f0:9610:559:7713:a305:7d30) (Ping timeout: 276 seconds) |
| 2024-09-15 14:45:52 +0200 | Sciencentistguy | (~sciencent@hacksoc/ordinary-member) (Quit: o/) |
| 2024-09-15 14:48:59 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2024-09-15 14:52:26 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-15 14:54:11 +0200 | sw4n | (~sw4n@2605:59c0:40f0:9610:559:7713:a305:7d30) |
| 2024-09-15 14:56:19 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2024-09-15 14:56:50 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 248 seconds) |
| 2024-09-15 15:01:38 +0200 | sw4n | (~sw4n@2605:59c0:40f0:9610:559:7713:a305:7d30) (Ping timeout: 248 seconds) |
| 2024-09-15 15:08:29 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-15 15:10:10 +0200 | krei-se- | (~krei-se@p57af2362.dip0.t-ipconnect.de) |
| 2024-09-15 15:10:12 +0200 | hughjfch1 | (~hughjfche@vmi556545.contaboserver.net) (Ping timeout: 252 seconds) |
| 2024-09-15 15:10:34 +0200 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) (Ping timeout: 252 seconds) |
| 2024-09-15 15:10:34 +0200 | krei-se | (~krei-se@p57af2362.dip0.t-ipconnect.de) (Ping timeout: 252 seconds) |
| 2024-09-15 15:10:34 +0200 | lbseale | (~quassel@user/ep1ctetus) (Ping timeout: 252 seconds) |
| 2024-09-15 15:11:00 +0200 | lbseale | (~quassel@user/ep1ctetus) |
| 2024-09-15 15:11:59 +0200 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) |
| 2024-09-15 15:12:10 +0200 | hughjfchen | (~hughjfche@vmi556545.contaboserver.net) |
| 2024-09-15 15:13:29 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 260 seconds) |
| 2024-09-15 15:15:20 +0200 | Xe | (~cadey@perl/impostor/xe) (Ping timeout: 252 seconds) |
| 2024-09-15 15:16:04 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Ping timeout: 252 seconds) |
| 2024-09-15 15:16:46 +0200 | euleritian | (~euleritia@dynamic-176-006-130-018.176.6.pool.telefonica.de) |
| 2024-09-15 15:16:49 +0200 | sw4n | (~sw4n@2605:59c0:40f0:9610:559:7713:a305:7d30) |
| 2024-09-15 15:17:27 +0200 | Xe | (~cadey@perl/impostor/xe) |
| 2024-09-15 15:21:09 +0200 | <jackdk> | lxsameer: Usually I use `:t` in a repl - most of the time when I need that I'm building up a complicated expression incrementally. But also the work that I do tends not to be super-high-powered haskell so there are a manageable number of type variables in play. I also use haddock pages on hackage pretty heavily because I'm usually asking "what functions might help solve my problem?" not "what is the type of this thing?" does that help? |
| 2024-09-15 15:21:48 +0200 | sw4n | (~sw4n@2605:59c0:40f0:9610:559:7713:a305:7d30) (Ping timeout: 276 seconds) |
| 2024-09-15 15:23:56 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-15 15:28:12 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 246 seconds) |
| 2024-09-15 15:29:40 +0200 | <Leary> | lxsameer: Just BTW, you can always put _ in an expression or type and let GHC(id) tell you what ought to go there. |
| 2024-09-15 15:31:55 +0200 | raym | (~ray@user/raym) |
| 2024-09-15 15:35:20 +0200 | sw4n | (~sw4n@2605:59c0:40f0:9610:559:7713:a305:7d30) |
| 2024-09-15 15:37:24 +0200 | kmein | (~weechat@user/kmein) (Ping timeout: 276 seconds) |
| 2024-09-15 15:39:45 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-15 15:39:53 +0200 | sw4n | (~sw4n@2605:59c0:40f0:9610:559:7713:a305:7d30) (Ping timeout: 252 seconds) |
| 2024-09-15 15:42:57 +0200 | cjay- | cjay |
| 2024-09-15 15:44:18 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2024-09-15 15:45:37 +0200 | euleritian | (~euleritia@dynamic-176-006-130-018.176.6.pool.telefonica.de) (Read error: Connection reset by peer) |
| 2024-09-15 15:46:44 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) |
| 2024-09-15 15:47:56 +0200 | <probie> | > let deleteFirst p xs = foldr (\x k q -> if q x then k (const False) else (x:) . k q) (const id) xs p [] in deleteFirst (> 5) [1..10] |
| 2024-09-15 15:47:57 +0200 | <lambdabot> | [1,2,3,4,5,7,8,9,10] |
| 2024-09-15 15:53:45 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Ping timeout: 265 seconds) |
| 2024-09-15 15:54:23 +0200 | gdown | (~gavin@h69-11-148-150.kndrid.broadband.dynamic.tds.net) |
| 2024-09-15 15:54:29 +0200 | <probie> | > let deleteFirst p = uncurry (++) . fmap (drop 1) . break p in deleteFirst (>5) [1..10] |
| 2024-09-15 15:54:30 +0200 | <lambdabot> | [1,2,3,4,5,7,8,9,10] |
| 2024-09-15 15:55:43 +0200 | euleritian | (~euleritia@dynamic-176-006-130-018.176.6.pool.telefonica.de) |
| 2024-09-15 15:57:47 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-15 16:02:16 +0200 | euleritian | (~euleritia@dynamic-176-006-130-018.176.6.pool.telefonica.de) (Ping timeout: 252 seconds) |
| 2024-09-15 16:02:27 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 265 seconds) |
| 2024-09-15 16:10:23 +0200 | euphores | (~SASL_euph@user/euphores) (Quit: Leaving.) |
| 2024-09-15 16:10:40 +0200 | weary-traveler | (~user@user/user363627) |
| 2024-09-15 16:11:39 +0200 | emaczen | (~user@user/emaczen) |
| 2024-09-15 16:13:45 +0200 | rubin55 | (sid666177@id-666177.lymington.irccloud.com) (Ping timeout: 260 seconds) |
| 2024-09-15 16:14:35 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-15 16:15:20 +0200 | euphores | (~SASL_euph@user/euphores) |
| 2024-09-15 16:16:26 +0200 | rubin55 | (sid666177@id-666177.lymington.irccloud.com) |
| 2024-09-15 16:18:19 +0200 | emaczen` | (~user@75-98-148-133.cpe.safelink.net) |
| 2024-09-15 16:19:08 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2024-09-15 16:22:22 +0200 | <lxsameer> | Leary: yeah, I'm aware of that, but some times i want to see the type of a symbol quickly |
| 2024-09-15 16:32:04 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-15 16:34:35 +0200 | <geekosaur> | I mouseover it in vscode 😛 |
| 2024-09-15 16:34:48 +0200 | Pozyomka | (~pyon@user/pyon) |
| 2024-09-15 16:36:54 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 260 seconds) |
| 2024-09-15 16:38:53 +0200 | Sciencentistguy | (~sciencent@hacksoc/ordinary-member) |
| 2024-09-15 16:39:36 +0200 | weary-traveler | (~user@user/user363627) (Quit: Konversation terminated!) |
| 2024-09-15 16:39:39 +0200 | <tomsmeding> | I hit K in my neovim lsp card house :p |
| 2024-09-15 16:40:23 +0200 | euleritian | (~euleritia@dynamic-176-002-004-162.176.2.pool.telefonica.de) |
| 2024-09-15 16:40:43 +0200 | <tomsmeding> | (why 'K', don't ask me) |
| 2024-09-15 16:40:57 +0200 | <tomsmeding> | (doKumentation?) |
| 2024-09-15 16:41:16 +0200 | <geekosaur> | because nvim's got no good keys left 😛 |
| 2024-09-15 16:41:22 +0200 | <tomsmeding> | that's more likely |
| 2024-09-15 16:41:38 +0200 | <geekosaur> | faceplant in a neovim session and something will happen |
| 2024-09-15 16:41:44 +0200 | <tomsmeding> | well, K is already "show man page" in normal vim |
| 2024-09-15 16:42:00 +0200 | <tomsmeding> | so it's a natural extension from that, but why K means "show man page" is not any clearer |
| 2024-09-15 16:42:27 +0200 | <tomsmeding> | it's not even `man -K`, it's just normal `man` |
| 2024-09-15 16:43:00 +0200 | <geekosaur> | they took away my `g` which was my go-to macro from the 1980s |
| 2024-09-15 16:43:27 +0200 | <tomsmeding> | as in go-to-file? |
| 2024-09-15 16:43:44 +0200 | <tomsmeding> | and vim already did that, that must have been vi |
| 2024-09-15 16:43:50 +0200 | <geekosaur> | I mean that was the first key I always bound in classical vi, yes |
| 2024-09-15 16:43:57 +0200 | <tomsmeding> | I see |
| 2024-09-15 16:44:18 +0200 | <tomsmeding> | well Bram apparently had the same idea and used it for all vim's stuff :p |
| 2024-09-15 16:44:23 +0200 | <tomsmeding> | well, g and z |
| 2024-09-15 16:45:15 +0200 | <geekosaur> | of course, that lost that `z` was left unbound deliberately as a guard around `ZZ` |
| 2024-09-15 16:45:55 +0200 | misterfish | (~misterfis@84.53.85.146) |
| 2024-09-15 16:45:56 +0200 | <tomsmeding> | most z actions are harmless, though |
| 2024-09-15 16:46:12 +0200 | <geekosaur> | right, the worry was that `ZZ` isn't |
| 2024-09-15 16:46:24 +0200 | <tomsmeding> | I z |
| 2024-09-15 16:46:31 +0200 | dyniec | (~dyniec@dybiec.info) |
| 2024-09-15 16:46:36 +0200 | <geekosaur> | so (a) it's doubled (b) `z` doesn't do anything useful to reduce chances of hitting `Z` instead |
| 2024-09-15 16:46:58 +0200 | <geekosaur> | original vi actually had a semi-rational command set design |
| 2024-09-15 16:47:03 +0200 | <tomsmeding> | did those keyboards have caps lock, in the time that vi's command set was designed? |
| 2024-09-15 16:47:19 +0200 | Sciencentistguy4 | (~sciencent@hacksoc/ordinary-member) |
| 2024-09-15 16:47:20 +0200 | <geekosaur> | yes |
| 2024-09-15 16:47:25 +0200 | <geekosaur> | (no num lock though) |
| 2024-09-15 16:47:28 +0200 | <tomsmeding> | then it's a risk, indeed |
| 2024-09-15 16:47:48 +0200 | <tomsmeding> | "no num lock" was the numpad just always numbers, or no numpad at all? |
| 2024-09-15 16:47:55 +0200 | <geekosaur> | the former |
| 2024-09-15 16:47:58 +0200 | <tomsmeding> | good |
| 2024-09-15 16:48:20 +0200 | <tomsmeding> | I never understood why one would want what is today "num lock off" |
| 2024-09-15 16:48:22 +0200 | <geekosaur> | the idea of the numpad turning into an arrow pad was a hack by the original IBM PC so they could make a more compact keyboard |
| 2024-09-15 16:48:48 +0200 | <geekosaur> | vi was written on 80s-style UNIX engineering workstations with big keyboards, so they had dedicated arrow pads |
| 2024-09-15 16:49:11 +0200 | Sciencentistguy | (~sciencent@hacksoc/ordinary-member) (Ping timeout: 252 seconds) |
| 2024-09-15 16:49:11 +0200 | Sciencentistguy4 | Sciencentistguy |
| 2024-09-15 16:49:24 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-15 16:52:14 +0200 | euleritian | (~euleritia@dynamic-176-002-004-162.176.2.pool.telefonica.de) (Ping timeout: 265 seconds) |
| 2024-09-15 16:52:36 +0200 | weary-traveler | (~user@user/user363627) |
| 2024-09-15 16:53:18 +0200 | emaczen | (~user@user/emaczen) (Ping timeout: 272 seconds) |
| 2024-09-15 16:53:24 +0200 | shawwwn | (sid6132@id-6132.helmsley.irccloud.com) (Ping timeout: 260 seconds) |
| 2024-09-15 16:53:27 +0200 | emaczen` | (~user@75-98-148-133.cpe.safelink.net) (Ping timeout: 276 seconds) |
| 2024-09-15 16:53:42 +0200 | spew | (~spew@201.141.99.170) |
| 2024-09-15 16:54:07 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 264 seconds) |
| 2024-09-15 16:54:32 +0200 | euleritian | (~euleritia@dynamic-176-006-143-017.176.6.pool.telefonica.de) |
| 2024-09-15 16:56:29 +0200 | euleritian | (~euleritia@dynamic-176-006-143-017.176.6.pool.telefonica.de) (Read error: Connection reset by peer) |
| 2024-09-15 16:56:54 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) |
| 2024-09-15 17:05:07 +0200 | zmt00 | (~zmt00@user/zmt00) |
| 2024-09-15 17:06:59 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-15 17:07:54 +0200 | misterfish | (~misterfis@84.53.85.146) (Ping timeout: 252 seconds) |
| 2024-09-15 17:08:37 +0200 | swamp_ | (~zmt00@user/zmt00) (Ping timeout: 252 seconds) |
| 2024-09-15 17:09:23 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2024-09-15 17:11:27 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 246 seconds) |
| 2024-09-15 17:11:36 +0200 | shawwwn | (sid6132@id-6132.helmsley.irccloud.com) |
| 2024-09-15 17:18:10 +0200 | athan | (~athan@syn-098-153-145-140.biz.spectrum.com) |
| 2024-09-15 17:23:18 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-15 17:27:48 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2024-09-15 17:34:22 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2024-09-15 17:39:54 +0200 | rosco | (~rosco@175.136.158.234) |
| 2024-09-15 17:41:30 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-15 17:46:01 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2024-09-15 17:57:21 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-15 17:59:42 +0200 | Inst_ | (~Inst@user/Inst) |
| 2024-09-15 18:01:55 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 264 seconds) |
| 2024-09-15 18:07:49 +0200 | <haskellbridge> | <thirdofmay18081814goya> what is the usual model of parallelism and concurrency when we model computations with monads? |
| 2024-09-15 18:09:30 +0200 | econo_ | (uid147250@id-147250.tinside.irccloud.com) |
| 2024-09-15 18:14:51 +0200 | gmg | (~user@user/gehmehgeh) (Ping timeout: 260 seconds) |
| 2024-09-15 18:15:15 +0200 | gmg | (~user@user/gehmehgeh) |
| 2024-09-15 18:15:37 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-15 18:16:45 +0200 | kmein | (~weechat@user/kmein) |
| 2024-09-15 18:17:20 +0200 | <monochrom> | I think there is none because they are orthogonal. |
| 2024-09-15 18:18:06 +0200 | <JuanDaugherty> | by which he means no consensus, if that's what usual means |
| 2024-09-15 18:18:57 +0200 | <JuanDaugherty> | ie. no single pkg, approach |
| 2024-09-15 18:19:32 +0200 | <JuanDaugherty> | physical is physical tho |
| 2024-09-15 18:20:08 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2024-09-15 18:20:19 +0200 | <haskellbridge> | <thirdofmay18081814goya> monochrom: how would you formalize parallelism or concurrency? |
| 2024-09-15 18:21:10 +0200 | gdown | (~gavin@h69-11-148-150.kndrid.broadband.dynamic.tds.net) (Remote host closed the connection) |
| 2024-09-15 18:21:24 +0200 | <JuanDaugherty> | STM is big |
| 2024-09-15 18:22:21 +0200 | JuanDaugherty | (~juan@user/JuanDaugherty) () |
| 2024-09-15 18:22:23 +0200 | <geekosaur> | I thoink "formalize" doesn't mean "do", it means "model"? |
| 2024-09-15 18:22:44 +0200 | <monochrom> | In theory, I prefer Communicating Sequential Processes or generally any messaging system. In practice, I recognize that we are stuck with shared memory and some weak consistency guarantee. |
| 2024-09-15 18:23:19 +0200 | <haskellbridge> | <thirdofmay18081814goya> monochrom: ah very cool! thanks a lot for the CSP reference |
| 2024-09-15 18:27:18 +0200 | telser | (~quassel@user/telser) (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) |
| 2024-09-15 18:30:20 +0200 | troojg | (~troojg@user/troojg) |
| 2024-09-15 18:30:43 +0200 | athan | (~athan@syn-098-153-145-140.biz.spectrum.com) (Quit: Konversation terminated!) |
| 2024-09-15 18:32:17 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-15 18:36:38 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 245 seconds) |
| 2024-09-15 18:37:06 +0200 | telser | (~quassel@user/telser) |
| 2024-09-15 18:49:31 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-15 18:53:52 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2024-09-15 18:54:56 +0200 | weary-traveler | (~user@user/user363627) (Read error: Connection reset by peer) |
| 2024-09-15 18:56:08 +0200 | youthlic | (~Thunderbi@user/youthlic) (Quit: youthlic) |
| 2024-09-15 19:07:53 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-15 19:09:32 +0200 | remedan | (~remedan@ip-62-245-108-153.bb.vodafone.cz) (Quit: Bye!) |
| 2024-09-15 19:10:21 +0200 | raehik | (~raehik@rdng-25-b2-v4wan-169990-cust1344.vm39.cable.virginm.net) |
| 2024-09-15 19:10:21 +0200 | remedan | (~remedan@ip-62-245-108-153.bb.vodafone.cz) |
| 2024-09-15 19:12:34 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2024-09-15 19:16:31 +0200 | billchenchina- | (~billchenc@103.152.35.21) |
| 2024-09-15 19:17:25 +0200 | mxs | (~mxs@user/mxs) (Quit: The Lounge - https://thelounge.chat) |
| 2024-09-15 19:22:08 +0200 | misterfish | (~misterfis@84.53.85.146) |
| 2024-09-15 19:23:21 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-15 19:23:28 +0200 | <raehik> | Is there any way to disable a single "redundant import" warning? (context, need to import Control.Monad.forM_ in mtl-2.3 / GHC 9.6, but it's re-exported in mtl-2.x) |
| 2024-09-15 19:26:52 +0200 | <tomsmeding> | nope |
| 2024-09-15 19:26:53 +0200 | euphores | (~SASL_euph@user/euphores) (Quit: Leaving.) |
| 2024-09-15 19:27:15 +0200 | <tomsmeding> | in general there should be more ways to selectively disable diagnostics/warnings/etc; -Worphans is another candidate |
| 2024-09-15 19:27:19 +0200 | tzh | (~tzh@c-76-115-131-146.hsd1.or.comcast.net) |
| 2024-09-15 19:27:58 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2024-09-15 19:28:02 +0200 | <tomsmeding> | the typical solution is to use CPP (#if !MIN_VERSION_mtl(2,4,0) \n import Control.Monad (forM_) \n #endif) |
| 2024-09-15 19:28:06 +0200 | <raehik> | oh yeah that would be nice. my orphans tend to be placed in separate modules anyway so I don't feel that so much |
| 2024-09-15 19:28:23 +0200 | <tomsmeding> | but getting out CPP for just a warning is perhaps a bit overkill |
| 2024-09-15 19:28:37 +0200 | <raehik> | gotcha, and yup I can't introduce CPP here |
| 2024-09-15 19:28:47 +0200 | <tomsmeding> | ("can't"?) |
| 2024-09-15 19:28:49 +0200 | <mauke> | how do I trigger that warning? |
| 2024-09-15 19:28:59 +0200 | <tomsmeding> | mauke: import something twice |
| 2024-09-15 19:29:03 +0200 | <raehik> | (...don't want to xd) |
| 2024-09-15 19:29:08 +0200 | <tomsmeding> | raehik: ah :p |
| 2024-09-15 19:29:08 +0200 | <mauke> | no, this exact case |
| 2024-09-15 19:29:27 +0200 | <raehik> | my previous solution was to add a comment on the import line so it shows up in the warning-- will continue to do so |
| 2024-09-15 19:29:49 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-15 19:29:58 +0200 | <raehik> | mauke: import some mtl-2.2.x module and Control.Monad |
| 2024-09-15 19:30:02 +0200 | <haskellbridge> | <Jade> scoped disabling of warnings would be a cool thing |
| 2024-09-15 19:30:07 +0200 | <haskellbridge> | <Jade> there's a ticket somewhere |
| 2024-09-15 19:30:14 +0200 | <raehik> | some of the mtl-2.2.x modules re-export Control.Monad and submodules |
| 2024-09-15 19:30:28 +0200 | <mauke> | what do you mean by "a mtl-2.2.x module"? |
| 2024-09-15 19:30:56 +0200 | <raehik> | a module from mtl, one of the 2.2 versions (before 2.3) |
| 2024-09-15 19:31:12 +0200 | <raehik> | not sure which modules re-export, probably like Control.Monad.State etc |
| 2024-09-15 19:31:16 +0200 | <tomsmeding> | (the CPP should have been: #if MIN_VERSION_mtl(2,4,0) \n import ... \n #endif) |
| 2024-09-15 19:31:37 +0200 | <tomsmeding> | e.g. https://hackage.haskell.org/package/mtl-2.2.2/docs/Control-Monad-Identity.html |
| 2024-09-15 19:31:45 +0200 | <tomsmeding> | (see the Control.Monad re-export) |
| 2024-09-15 19:31:49 +0200 | <raehik> | ahh thx tomsmeding |
| 2024-09-15 19:32:00 +0200 | <tomsmeding> | christ even now it's wrong |
| 2024-09-15 19:32:02 +0200 | <tomsmeding> | (2,3,0) |
| 2024-09-15 19:32:19 +0200 | <mauke> | Module ‘Control.Monad.Identity’ does not export ‘forM_’. -- guess I don't have the right (wrong) version |
| 2024-09-15 19:32:34 +0200 | <tomsmeding> | mauke: which version do you have :p |
| 2024-09-15 19:32:40 +0200 | <mauke> | no idea |
| 2024-09-15 19:32:41 +0200 | <monochrom> | Actually I don't think re-exports causes redundant import warning. Or is it because I didn't turn on -Wall-anal-warnings? |
| 2024-09-15 19:32:47 +0200 | <tomsmeding> | mauke: how are you trying it? ghci? |
| 2024-09-15 19:32:50 +0200 | <mauke> | ghc |
| 2024-09-15 19:32:55 +0200 | <mauke> | actually, ghc -Wall |
| 2024-09-15 19:33:15 +0200 | <tomsmeding> | try opening it in ghci and typing `:show packages` |
| 2024-09-15 19:33:21 +0200 | <raehik> | GHC 9.6 packages mtl-2.3.1 https://downloads.haskell.org/ghc/9.6.1/docs/users_guide/9.6.1-notes.html |
| 2024-09-15 19:33:23 +0200 | <monochrom> | I've ever only seen unused imports, but even then I had to proactively ask for it. |
| 2024-09-15 19:33:30 +0200 | <raehik> | GHC 9.4 and before should package mtl-2.2.x |
| 2024-09-15 19:33:38 +0200 | <mauke> | active package flags: none |
| 2024-09-15 19:34:36 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 246 seconds) |
| 2024-09-15 19:34:52 +0200 | <tomsmeding> | https://play.haskell.org/saved/Ldlipq0S this gives a redundant import warning in any case |
| 2024-09-15 19:35:01 +0200 | <tomsmeding> | (for obvious reasons) |
| 2024-09-15 19:35:07 +0200 | <tomsmeding> | monochrom: yes, people enable -Wall |
| 2024-09-15 19:35:33 +0200 | euphores | (~SASL_euph@user/euphores) |
| 2024-09-15 19:36:10 +0200 | <mauke> | raehik: import qualified Control.Monad as M; ... M.forM_ |
| 2024-09-15 19:36:11 +0200 | <raehik> | `-Wall -Wno-unticked-promoted-constructors` is my goto |
| 2024-09-15 19:36:28 +0200 | <tomsmeding> | raehik: that -Wno-... is unnecessary since recent ghcs |
| 2024-09-15 19:36:31 +0200 | <raehik> | mauke: yeah I could do that..... but it's annoying :D it's not just forM_ |
| 2024-09-15 19:36:55 +0200 | <raehik> | tomsmeding: yeah since GHC 9.4. but I still support GHC 9.2 in some of my projs so it stays a default for now |
| 2024-09-15 19:37:49 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2024-09-15 19:39:30 +0200 | <tomsmeding> | mauke: oh actually, here's a reproducer: https://play.haskell.org/saved/4NaXDNzu |
| 2024-09-15 19:39:38 +0200 | <tomsmeding> | gives a redundant import warning with ghc 9.4 but not with 9.6 |
| 2024-09-15 19:39:46 +0200 | <tomsmeding> | I didn't realise mtl was wired in |
| 2024-09-15 19:40:22 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-15 19:40:53 +0200 | <Hecate> | eyo |
| 2024-09-15 19:40:58 +0200 | <Hecate> | https://blog.haskell.org/the-haskell-playground/ <- nice article tomsmeding :D |
| 2024-09-15 19:41:18 +0200 | <tomsmeding> | Hecate: doesn't look live yet to me |
| 2024-09-15 19:41:29 +0200 | <tomsmeding> | oh it is, my browser was just caching the wrong thing |
| 2024-09-15 19:41:58 +0200 | <tomsmeding> | lol I can only see that in a private window |
| 2024-09-15 19:41:58 +0200 | <Hecate> | :3 |
| 2024-09-15 19:42:01 +0200 | <Hecate> | damnit |
| 2024-09-15 19:42:02 +0200 | <Hecate> | hmm |
| 2024-09-15 19:42:21 +0200 | <tomsmeding> | the redirect is cached and I can't force-reload anything (ignoring cache) because... it redirects immediately |
| 2024-09-15 19:44:10 +0200 | <tomsmeding> | but yay, cheers for launching |
| 2024-09-15 19:44:28 +0200 | <Hecate> | tomsmeding: you have kill the service worker! |
| 2024-09-15 19:44:37 +0200 | <Hecate> | if you use Firefox, go there: about:debugging#/runtime/this-firefox |
| 2024-09-15 19:45:07 +0200 | <monochrom> | I just didn't know -Wall also warns redundant imports where the imports are not syntactically redundant. |
| 2024-09-15 19:45:43 +0200 | <tomsmeding> | Hecate: a browser restart didn't help, but that did it O.o |
| 2024-09-15 19:45:59 +0200 | <monochrom> | I mean, no one really does "Control.Monad, then Control.Monad again for (forM_)". But everyone is entitled to do "Control.Monad and Control.Monad.State" and shouldn't need to worry about it. |
| 2024-09-15 19:46:25 +0200 | <tomsmeding> | monochrom: I agree it's a little overzealous |
| 2024-09-15 19:47:19 +0200 | <monochrom> | With C I turn on -Wall because every warning there is just cause. With GHC, -Wall is a lot of noise. |
| 2024-09-15 19:47:39 +0200 | troojg | (~troojg@user/troojg) (Ping timeout: 260 seconds) |
| 2024-09-15 19:48:45 +0200 | <raehik> | in my own projects I tend not to get too much -Wall noise. but yes larger projects it's a bit much and requires sifting (which partly defeats the purpose.... but imo not fully) |
| 2024-09-15 19:50:09 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 260 seconds) |
| 2024-09-15 19:50:26 +0200 | <dolio> | GHC has multiple warning about things where the code required to avoid the warning is arguably worse than what it's warning about. |
| 2024-09-15 19:51:09 +0200 | <monochrom> | tomsmeding: About the playground, so is docker too bloated that you declined and did your own systemd-run and bwrap? |
| 2024-09-15 19:51:52 +0200 | <tomsmeding> | monochrom: I have heard from various directions that docker is meant as an environment reproducibility tool, not a sandboxing tool, and hence it's unwise to rely on it for sandboxing |
| 2024-09-15 19:52:07 +0200 | <Hecate> | tomsmeding: yeah I really don't like PWAs… |
| 2024-09-15 19:52:09 +0200 | <tomsmeding> | maerwald (of ghcup fame) liked bwrap, and I have 0 knowledge in this space, so I trusted him |
| 2024-09-15 19:53:21 +0200 | misterfish | (~misterfis@84.53.85.146) (Ping timeout: 248 seconds) |
| 2024-09-15 20:00:57 +0200 | pavonia | (~user@user/siracusa) (Quit: Bye!) |
| 2024-09-15 20:01:14 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2024-09-15 20:03:07 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-15 20:05:44 +0200 | raehik | (~raehik@rdng-25-b2-v4wan-169990-cust1344.vm39.cable.virginm.net) (Ping timeout: 260 seconds) |
| 2024-09-15 20:07:34 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2024-09-15 20:08:24 +0200 | myxos | (~myxos@syn-065-028-251-121.res.spectrum.com) (Ping timeout: 252 seconds) |
| 2024-09-15 20:09:52 +0200 | billchenchina- | (~billchenc@103.152.35.21) (Remote host closed the connection) |
| 2024-09-15 20:10:18 +0200 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) |
| 2024-09-15 20:13:11 +0200 | athan | (~athan@syn-098-153-145-140.biz.spectrum.com) |
| 2024-09-15 20:17:04 +0200 | myxos | (~myxos@syn-065-028-251-121.res.spectrum.com) |
| 2024-09-15 20:19:40 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-15 20:21:40 +0200 | k_hachig_ | (~k_hachig@2607:fea8:351d:ef0:e8aa:5287:babe:ddb5) |
| 2024-09-15 20:22:03 +0200 | k_hachig_ | k_hachig |
| 2024-09-15 20:24:42 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 276 seconds) |
| 2024-09-15 20:25:16 +0200 | <lxsameer> | hey friends, is there any immutable refrence type in Haskell? |
| 2024-09-15 20:29:30 +0200 | <monochrom> | No. |
| 2024-09-15 20:29:33 +0200 | <[exa]> | lxsameer: technically all values are immutable references, but I guess you want something that behaves more explicitly as a reference? |
| 2024-09-15 20:29:56 +0200 | myxos | (~myxos@syn-065-028-251-121.res.spectrum.com) (Ping timeout: 252 seconds) |
| 2024-09-15 20:30:08 +0200 | <dmj`> | lxsameer: like an IORef or Ptr where you can't mutate the underlying value? |
| 2024-09-15 20:31:12 +0200 | <monochrom> | Actually, perhaps StableName. |
| 2024-09-15 20:31:20 +0200 | myxos | (~myxos@syn-065-028-251-121.res.spectrum.com) |
| 2024-09-15 20:35:09 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-15 20:35:47 +0200 | <tomsmeding> | lxsameer: what exactly would you be able to do with an "immutable reference type" that you can't do with just... an immutable value? |
| 2024-09-15 20:36:43 +0200 | <geekosaur> | yeh, I'm confused by what the question is about. XY problem perhaps? |
| 2024-09-15 20:37:52 +0200 | <geekosaur> | as stated above, all normal Haskell values are references. unboxed values by definition aren't, but you normally let the compiler deal with those. |
| 2024-09-15 20:38:16 +0200 | raehik | (~raehik@rdng-25-b2-v4wan-169990-cust1344.vm39.cable.virginm.net) |
| 2024-09-15 20:38:18 +0200 | <tomsmeding> | (and in any case, if you're using unboxed values, you're typically quite explicitly choosing to do so) |
| 2024-09-15 20:38:24 +0200 | <[exa]> | I can imagine a read-only Ptr to statically linked data as a sensible use, but not much more tbh |
| 2024-09-15 20:38:43 +0200 | <tomsmeding> | make a ByteString from it? |
| 2024-09-15 20:39:42 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 246 seconds) |
| 2024-09-15 20:40:14 +0200 | <[exa]> | bytestring is able to avoid copying it out? |
| 2024-09-15 20:40:44 +0200 | <tomsmeding> | yes, but it's on the programmer to promise that that's safe |
| 2024-09-15 20:40:59 +0200 | <tomsmeding> | [exa]: https://hackage.haskell.org/package/bytestring-0.12.1.0/docs/Data-ByteString-Unsafe.html#v:unsafeP… |
| 2024-09-15 20:41:17 +0200 | <[exa]> | ah yes, lovely, forgot to add the unsafe there |
| 2024-09-15 20:41:28 +0200 | <[exa]> | long live bytestring the new immutable reference |
| 2024-09-15 20:41:32 +0200 | <tomsmeding> | well, it's good that it has "unsafe" in the name :p |
| 2024-09-15 20:41:40 +0200 | <tomsmeding> | immutable reference to _byte array_ data |
| 2024-09-15 20:42:02 +0200 | <tomsmeding> | oh, you want an immutable reference: data Box a = Box a |
| 2024-09-15 20:42:04 +0200 | <tomsmeding> | here you go! |
| 2024-09-15 20:42:29 +0200 | <[exa]> | btw technically "as long as the programmer promises that it's safe" w.r.t. immutability is roughly equivalent to the usual "as long as the programmer promises not to typecast the `const` away" |
| 2024-09-15 20:42:50 +0200 | <tomsmeding> | technically true, but here there is not necessarily a const to typecast away |
| 2024-09-15 20:42:59 +0200 | <tomsmeding> | in C you have to actually do a cast there |
| 2024-09-15 20:43:17 +0200 | <tomsmeding> | the CStringLen that you pass to unsafePackAsCStringLen could well be a mutable pointer, and then you're not casting anything |
| 2024-09-15 20:43:40 +0200 | <tomsmeding> | so it's "less safe" than a `const uint8_t*` in C (which in itself is already not very safe, but it's C so) |
| 2024-09-15 20:43:51 +0200 | <[exa]> | "relatively safe" |
| 2024-09-15 20:44:12 +0200 | <tomsmeding> | "relative" in the mathematical sense: relative to a proof by the programmer that the data will not be modified :p |
| 2024-09-15 20:44:13 +0200 | myxos | (~myxos@syn-065-028-251-121.res.spectrum.com) (Ping timeout: 252 seconds) |
| 2024-09-15 20:44:37 +0200 | AlexZenon | (~alzenon@94.233.241.202) (Ping timeout: 248 seconds) |
| 2024-09-15 20:46:00 +0200 | myxos | (~myxos@syn-065-028-251-121.res.spectrum.com) |
| 2024-09-15 20:48:28 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2024-09-15 20:49:15 +0200 | myxokephale | (~myxos@syn-065-028-251-121.res.spectrum.com) |
| 2024-09-15 20:50:22 +0200 | myxos | (~myxos@syn-065-028-251-121.res.spectrum.com) (Read error: Connection reset by peer) |
| 2024-09-15 20:51:34 +0200 | raehik | (~raehik@rdng-25-b2-v4wan-169990-cust1344.vm39.cable.virginm.net) (Ping timeout: 252 seconds) |
| 2024-09-15 20:51:46 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-15 20:52:04 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2024-09-15 20:52:25 +0200 | <ski> | i could imagine they wanted `instance Eq (Box a)' |
| 2024-09-15 20:52:41 +0200 | euandreh | (~Thunderbi@189.6.105.228) |
| 2024-09-15 20:53:10 +0200 | <monochrom> | StableName gets sufficiently close to that. |
| 2024-09-15 20:53:14 +0200 | <ski> | (you could use it to traverse (possibly cyclic) graphs) |
| 2024-09-15 20:53:22 +0200 | <ski> | there's also `IVar' |
| 2024-09-15 20:53:41 +0200 | <ski> | @hackage ivar-simple |
| 2024-09-15 20:53:41 +0200 | <lambdabot> | https://hackage.haskell.org/package/ivar-simple |
| 2024-09-15 20:53:46 +0200 | <ski> | @hackage data-ivar |
| 2024-09-15 20:53:46 +0200 | <lambdabot> | https://hackage.haskell.org/package/data-ivar |
| 2024-09-15 20:54:26 +0200 | <lxsameer> | [exa]: indeed |
| 2024-09-15 20:54:31 +0200 | <EvanR> | was about to say ivar |
| 2024-09-15 20:54:39 +0200 | <lxsameer> | dmj`: yeah |
| 2024-09-15 20:54:52 +0200 | <EvanR> | literally an immutable var |
| 2024-09-15 20:55:05 +0200 | <tomsmeding> | lxsameer: why is just a value not enough? Note that haskell is lazy |
| 2024-09-15 20:55:20 +0200 | <tomsmeding> | > let fibs = 0 : 1 : zipWith (+) fibs (tail fibs) in fibs |
| 2024-09-15 20:55:21 +0200 | <lambdabot> | [0,1,1,2,3,5,8,13,21,34,55,89,144,233,377,610,987,1597,2584,4181,6765,10946,... |
| 2024-09-15 20:55:25 +0200 | <ski> | tomsmeding : `Eq' ? |
| 2024-09-15 20:55:26 +0200 | <monochrom> | But generally this is why I have the hot take unpopular opinion that a data type is not defined by how you would implement its data structure, but rather by what operations you expect of it. |
| 2024-09-15 20:55:32 +0200 | AlexZenon | (~alzenon@94.233.241.202) |
| 2024-09-15 20:55:51 +0200 | <tomsmeding> | ski: you want pointer equality? |
| 2024-09-15 20:55:51 +0200 | <lxsameer> | tomsmeding: I'm trying to avoid copying data. Hopefully ghc is smart enough to do that, but since I don't know about how ghc works, I asked the question |
| 2024-09-15 20:55:58 +0200 | <EvanR> | the rubick's cube is all about the moves and not the cube itself |
| 2024-09-15 20:56:05 +0200 | <ski> | tomsmeding : that could be one way to implement it, sure |
| 2024-09-15 20:56:07 +0200 | <tomsmeding> | lxsameer: _everything_ in a haskell program is a refrence |
| 2024-09-15 20:56:11 +0200 | <monochrom> | In this example, "a pointer to my value" is unhelpful, "I need pointer equality, like identity in Java" is helpful. |
| 2024-09-15 20:56:20 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2024-09-15 20:56:25 +0200 | <ski> | tomsmeding : or just increment a counter in a state monad |
| 2024-09-15 20:56:27 +0200 | <monochrom> | s/identity/object identity/ |
| 2024-09-15 20:56:28 +0200 | <tomsmeding> | (unless you explicitly say you want a non-reference type, i.e. an _unboxed_ type, but those are marked with a '#', like Int#) |
| 2024-09-15 20:56:40 +0200 | <tomsmeding> | nothing will be copied if you just pass values around |
| 2024-09-15 20:56:52 +0200 | <EvanR> | is unboxed array a non-reference type xD |
| 2024-09-15 20:56:59 +0200 | <tomsmeding> | monochrom: agreed |
| 2024-09-15 20:57:30 +0200 | <monochrom> | Extreme example: "how do I make an infinite set?" is informationless. |
| 2024-09-15 20:57:36 +0200 | tabemann | (~tabemann@2600:1700:7990:24e0:f2d2:5bad:a45f:c15b) (Remote host closed the connection) |
| 2024-09-15 20:57:43 +0200 | <tomsmeding> | EvanR: which type are you talking about, precisely? |
| 2024-09-15 20:57:50 +0200 | tabemann | (~tabemann@2600:1700:7990:24e0:6b51:c8e0:844c:e9ca) |
| 2024-09-15 20:58:04 +0200 | <monochrom> | You must give up some of the usual set operations, and you haven't said which. |
| 2024-09-15 20:58:12 +0200 | <tomsmeding> | (e.g. ByteArray# is _unlifted_, not unboxed; that's something different) |
| 2024-09-15 20:58:20 +0200 | <monochrom> | Extreme answer: "()". >:) |
| 2024-09-15 20:58:59 +0200 | <tomsmeding> | monochrom: in this case, however, it turned out that the question was not about explicit operations on the data, but on what the _implicit_ copy operation does on data |
| 2024-09-15 21:00:02 +0200 | caconym | (~caconym@user/caconym) (Quit: bye) |
| 2024-09-15 21:00:34 +0200 | myxokephale | (~myxos@syn-065-028-251-121.res.spectrum.com) (Ping timeout: 260 seconds) |
| 2024-09-15 21:00:37 +0200 | caconym | (~caconym@user/caconym) |
| 2024-09-15 21:00:47 +0200 | <EvanR> | monochrom, clearly they are implying all standard operations on a set, union, intersection, "element of" xD |
| 2024-09-15 21:01:03 +0200 | hueso | (~root@user/hueso) (Quit: hueso) |
| 2024-09-15 21:01:14 +0200 | <monochrom> | I hope they also include set equality. |
| 2024-09-15 21:01:49 +0200 | myxos | (~myxos@syn-065-028-251-121.res.spectrum.com) |
| 2024-09-15 21:01:50 +0200 | <EvanR> | cardinality of |
| 2024-09-15 21:02:34 +0200 | hueso | (~root@user/hueso) |
| 2024-09-15 21:02:50 +0200 | <monochrom> | And a choice function >:) |
| 2024-09-15 21:03:03 +0200 | <tomsmeding> | uniformly random, please |
| 2024-09-15 21:03:18 +0200 | mreh | (~matthew@host86-160-168-12.range86-160.btcentralplus.com) (Ping timeout: 252 seconds) |
| 2024-09-15 21:03:20 +0200 | rvalue- | (~rvalue@user/rvalue) |
| 2024-09-15 21:04:00 +0200 | <[exa]> | lxsameer: any specific example on where you are trying to avoid copies? notably, ghc is not going to copy (not even materialize!) anything that you don't try to take apart (and reassemble manually) |
| 2024-09-15 21:04:03 +0200 | rvalue | (~rvalue@user/rvalue) (Ping timeout: 265 seconds) |
| 2024-09-15 21:04:09 +0200 | <probie> | A choice function on an infinite set? Next you'll be asking me to turn a ball into two identical balls using 5 cuts |
| 2024-09-15 21:04:51 +0200 | causal | (~eric@50.35.88.207) |
| 2024-09-15 21:05:07 +0200 | <monochrom> | That's user-definable so we will leave it to 3rd-party libraries. >:) |
| 2024-09-15 21:05:37 +0200 | myxos | (~myxos@syn-065-028-251-121.res.spectrum.com) (Remote host closed the connection) |
| 2024-09-15 21:06:20 +0200 | myxos | (~myxos@syn-065-028-251-121.res.spectrum.com) |
| 2024-09-15 21:06:24 +0200 | hueso | (~root@user/hueso) (Client Quit) |
| 2024-09-15 21:07:33 +0200 | <lxsameer> | [exa]: cool good to know |
| 2024-09-15 21:08:33 +0200 | hueso | (~root@user/hueso) |
| 2024-09-15 21:08:47 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-15 21:09:29 +0200 | rvalue- | rvalue |
| 2024-09-15 21:09:31 +0200 | <[exa]> | lxsameer: actually it's a kinda side outcome of the laziness -- for example you are guaranteed to be able to safely change a few first elements of a list which contains an error or is infinite or so. Haskell can't assume that copying of the rest of the list is "safe" because there might be something that triggers an error, and the usual solution is that it just doesn't touch it at all unless |
| 2024-09-15 21:09:33 +0200 | <[exa]> | absolutely forced to |
| 2024-09-15 21:10:34 +0200 | <tomsmeding> | > head [42, undefined, error "what"] |
| 2024-09-15 21:10:35 +0200 | <lambdabot> | 42 |
| 2024-09-15 21:10:56 +0200 | <probie> | > length [error "oh no"] |
| 2024-09-15 21:10:58 +0200 | <lambdabot> | 1 |
| 2024-09-15 21:11:14 +0200 | <[exa]> | ah perfect ^ |
| 2024-09-15 21:11:35 +0200 | <lxsameer> | pretty cool |
| 2024-09-15 21:12:03 +0200 | <monochrom> | I think it's the other way round. Lisp Scheme ML etc all did this since way back, so eager and impure languages do it too. Laziness was invented later and took advantage of it. |
| 2024-09-15 21:12:31 +0200 | <monochrom> | Not to mention, like, Java when it comes to objects. >:) |
| 2024-09-15 21:12:54 +0200 | <[exa]> | yeah there's this laziness vs actual laziness. :D |
| 2024-09-15 21:13:12 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2024-09-15 21:14:02 +0200 | <EvanR> | I like how the clojure lazy list evaluates like 32 elements at a time, so if you only look at the first 5 things, it might trigger an error on item 29 as a side effect |
| 2024-09-15 21:14:18 +0200 | <EvanR> | keeps you on your toes |
| 2024-09-15 21:14:31 +0200 | <dolio> | Yeah, that sounds great. |
| 2024-09-15 21:15:03 +0200 | <haskellbridge> | <Bowuigi> I guess it is a certified JVM moment |
| 2024-09-15 21:15:16 +0200 | <[exa]> | lol |
| 2024-09-15 21:15:55 +0200 | <EvanR> | it's just like haskell, if there are no errors or bugs anywhere, reasoning gets simpler xD |
| 2024-09-15 21:16:15 +0200 | <haskellbridge> | <Bowuigi> You could always "data SuperLazyList a = Nil | Cons (() -> a) (() -> SuperLazyList a)" |
| 2024-09-15 21:17:07 +0200 | euandreh | (~Thunderbi@189.6.105.228) (Quit: euandreh) |
| 2024-09-15 21:17:15 +0200 | <haskellbridge> | <Bowuigi> Tho the initial constructor is not lazy enough so you might want to "type SLL a = () -> SuperLazyList a" |
| 2024-09-15 21:17:17 +0200 | <monochrom> | ()->Foo easily kills the sharing we were talking about. |
| 2024-09-15 21:17:18 +0200 | <dolio> | Realistically, you should probably not be depending on that sort of difference. |
| 2024-09-15 21:18:16 +0200 | <dolio> | Although it seems like you might have to worry about it for various infinite definitions involving lists. |
| 2024-09-15 21:19:06 +0200 | <[exa]> | we should leave `()->Foo` to javascript and pals |
| 2024-09-15 21:19:31 +0200 | <monochrom> | But OK on the bright side, "sum xs / length xs" suffers from sharing and could benefit from re-computation. |
| 2024-09-15 21:20:15 +0200 | <EvanR> | dupthunk |
| 2024-09-15 21:20:27 +0200 | <monochrom> | Ugh symmetry fix: s/re-computation/re-computing/ # heh |
| 2024-09-15 21:20:38 +0200 | <dolio> | I.E. I don't think you should be worried about exactly the behavior of actual exceptions. You should worry about how reasoning about them implies things about well-defined programs. |
| 2024-09-15 21:21:34 +0200 | <haskellbridge> | <Bowuigi> "Fast and loose reasoning is morally correct"? |
| 2024-09-15 21:22:08 +0200 | <dolio> | No, that's something different. |
| 2024-09-15 21:22:49 +0200 | <dolio> | Reasoning about how your program acts with ⊥ is a coarse approximation of the operational behavior of your program. |
| 2024-09-15 21:24:08 +0200 | <dolio> | So, you probably don't care about how your program acts if fed with a list with a bomb in it, because it won't be fed that. But reasoning about that can tell you things about how it will act somewhat operationally on the lists it will be fed. |
| 2024-09-15 21:26:20 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-15 21:26:28 +0200 | <dolio> | Like, it would be unsurprising if the clojure lists can't handle `l = 1 : <some expression involving l`, because you need an entire chunk to be properly lazy, not just however much the expression needs. |
| 2024-09-15 21:27:50 +0200 | <dolio> | Unless there's some special support to turn expressions like that into code that works with chunks. |
| 2024-09-15 21:28:43 +0200 | AlexZenon_2 | (~alzenon@94.233.241.202) |
| 2024-09-15 21:29:41 +0200 | <monochrom> | Probably the intention was just streaming, rather than laziness. |
| 2024-09-15 21:29:46 +0200 | euphores | (~SASL_euph@user/euphores) (Quit: Leaving.) |
| 2024-09-15 21:29:57 +0200 | AlexZenon | (~alzenon@94.233.241.202) (Ping timeout: 248 seconds) |
| 2024-09-15 21:30:20 +0200 | <dolio> | Yeah. |
| 2024-09-15 21:30:47 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2024-09-15 21:31:04 +0200 | <EvanR> | good question haven't tried that |
| 2024-09-15 21:31:34 +0200 | AlexZenon_2 | AlexZenon |
| 2024-09-15 21:32:36 +0200 | synchromesh | (~john@2406:5a00:241a:5600:16f:d6b6:8ecf:f15b) (Read error: Connection reset by peer) |
| 2024-09-15 21:33:47 +0200 | synchromesh | (~john@2406:5a00:241a:5600:71fc:6cae:c163:498e) |
| 2024-09-15 21:35:11 +0200 | rosco | (~rosco@175.136.158.234) (Quit: Lost terminal) |
| 2024-09-15 21:38:21 +0200 | euphores | (~SASL_euph@user/euphores) |
| 2024-09-15 21:40:10 +0200 | mxs | (~mxs@user/mxs) |
| 2024-09-15 21:42:12 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-15 21:50:10 +0200 | <[exa]> | how bad is it to traverse stuff "via Compose" if I'm just too lazy to squash a few levels of the traversables myself? |
| 2024-09-15 21:50:32 +0200 | <[exa]> | (it really helps with mapAccum and pals) |
| 2024-09-15 21:51:06 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 246 seconds) |
| 2024-09-15 22:03:10 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-15 22:04:51 +0200 | Sgeo | (~Sgeo@user/sgeo) |
| 2024-09-15 22:07:56 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 255 seconds) |
| 2024-09-15 22:12:55 +0200 | <monochrom> | If "bad" refers to slow, I don't know. If "bad" refers to ugly, generally too-lazy-to-write-more-code iff beautiful. :) |
| 2024-09-15 22:14:48 +0200 | <monochrom> | perhaps s/more-code/more-mundane-code/ |
| 2024-09-15 22:20:20 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-15 22:20:23 +0200 | <probie> | % traverse print $ (coerce :: [[[Int]]] -> Compose (Compose [] []) [] Int) [[[1],[2,3]],[[4],[5,6]]] |
| 2024-09-15 22:20:23 +0200 | <yahb2> | 1 ; 2 ; 3 ; 4 ; 5 ; 6 ; Compose (Compose [[[()],[(),()]],[[()],[(),()]]]) |
| 2024-09-15 22:20:32 +0200 | <probie> | as in that sort of thing? |
| 2024-09-15 22:21:57 +0200 | wootehfoot | (~wootehfoo@user/wootehfoot) (Read error: Connection reset by peer) |
| 2024-09-15 22:22:00 +0200 | neuroevolutus | (~neuroevol@37.19.200.152) |
| 2024-09-15 22:25:36 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 276 seconds) |
| 2024-09-15 22:27:21 +0200 | tcard_ | (~tcard@2400:4051:5801:7500:cf17:befc:ff82:5303) (Quit: Leaving) |
| 2024-09-15 22:30:03 +0200 | bionade24 | (~quassel@2a03:4000:33:45b::1) (Quit: Apocalypse Incoming!) |
| 2024-09-15 22:30:13 +0200 | bionade24 | (~quassel@2a03:4000:33:45b::1) |
| 2024-09-15 22:32:20 +0200 | barrucadu | (~barrucadu@carcosa.barrucadu.co.uk) (Quit: Lost terminal) |
| 2024-09-15 22:33:39 +0200 | barrucadu | (~barrucadu@carcosa.barrucadu.co.uk) |
| 2024-09-15 22:34:36 +0200 | sourcetarius | (~sourcetar@user/sourcetarius) (Quit: sourcetarius) |
| 2024-09-15 22:35:34 +0200 | sourcetarius | (~sourcetar@user/sourcetarius) |
| 2024-09-15 22:36:12 +0200 | mxs | (~mxs@user/mxs) (Quit: The Lounge - https://thelounge.chat) |
| 2024-09-15 22:36:29 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-15 22:36:44 +0200 | solution | (~Solution@85-66-208-144.pool.digikabel.hu) (Ping timeout: 255 seconds) |
| 2024-09-15 22:40:48 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 245 seconds) |
| 2024-09-15 22:41:44 +0200 | tcard | (~tcard@2400:4051:5801:7500:cf17:befc:ff82:5303) |
| 2024-09-15 22:51:29 +0200 | michalz | (~michalz@185.246.207.203) (Remote host closed the connection) |
| 2024-09-15 22:51:32 +0200 | target_i | (~target_i@user/target-i/x-6023099) (Quit: leaving) |
| 2024-09-15 22:54:51 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-15 22:55:04 +0200 | takuan | (~takuan@178-116-218-225.access.telenet.be) (Remote host closed the connection) |
| 2024-09-15 22:56:52 +0200 | JuanDaugherty | (~juan@user/JuanDaugherty) |
| 2024-09-15 22:57:14 +0200 | lxsameer | (~lxsameer@Serene/lxsameer) (Ping timeout: 260 seconds) |
| 2024-09-15 22:59:34 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 265 seconds) |
| 2024-09-15 23:03:35 +0200 | mreh | (~matthew@host86-160-168-12.range86-160.btcentralplus.com) |
| 2024-09-15 23:09:05 +0200 | foul_owl | (~kerry@174-21-143-250.tukw.qwest.net) (Ping timeout: 260 seconds) |
| 2024-09-15 23:13:11 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-15 23:18:14 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 260 seconds) |
| 2024-09-15 23:21:30 +0200 | k_hachig | (~k_hachig@2607:fea8:351d:ef0:e8aa:5287:babe:ddb5) (Ping timeout: 276 seconds) |
| 2024-09-15 23:23:23 +0200 | foul_owl | (~kerry@185.219.141.160) |
| 2024-09-15 23:24:29 +0200 | <mauke> | https://pvp.haskell.org/#decision-tree is pretty nutty |
| 2024-09-15 23:25:02 +0200 | <mauke> | does anyone actually do the (A+1).B.C or A.(B+1).C stuff? |
| 2024-09-15 23:25:55 +0200 | <mauke> | I feel most people would go for (A+1).0.0 or A.(B+1).0 |
| 2024-09-15 23:26:44 +0200 | <haskellbridge> | <Jade> isn't that what they meant? I'm aware that it's not what it says but it feels like that's what they want to convey |
| 2024-09-15 23:27:44 +0200 | <monochrom> | Most people set zero the lower bits, yeah. |
| 2024-09-15 23:28:36 +0200 | <monochrom> | But dBase II is an example of someone skipping a lot of normal version numbers and starting at 2 right at the beginning. :) |
| 2024-09-15 23:28:56 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-15 23:29:31 +0200 | <monochrom> | https://en.wikipedia.org/wiki/DBase#Ashton-Tate |
| 2024-09-15 23:30:23 +0200 | <geekosaur> | looked at the version history of HTTP (the Hackage package, not the protocol) recently? |
| 2024-09-15 23:30:37 +0200 | <geekosaur> | or for that matter filepath |
| 2024-09-15 23:30:48 +0200 | <meejah> | or latex/web ;) |
| 2024-09-15 23:31:17 +0200 | <geekosaur> | then again maybe they're thinking of how TeX version numbers work 😛 |
| 2024-09-15 23:33:53 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 265 seconds) |
| 2024-09-15 23:34:10 +0200 | <monochrom> | It is not wrong do go from, e.g., 1.4.3 to 2.1.7. There is no need to require people to reset to zero. PVP is not a control freak. |
| 2024-09-15 23:34:38 +0200 | <monochrom> | Determinism is overrated. |
| 2024-09-15 23:36:21 +0200 | mreh | (~matthew@host86-160-168-12.range86-160.btcentralplus.com) (Ping timeout: 248 seconds) |
| 2024-09-15 23:36:49 +0200 | <mauke> | PVP requires that a breaking change from 1.4.3 go to either 2.4.3 or 1.5.3 |
| 2024-09-15 23:37:53 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2024-09-15 23:38:07 +0200 | <monochrom> | Hrm, you're right, it says that. |
| 2024-09-15 23:40:14 +0200 | <mauke> | it mentions Data.Version.Version, but does not say whether version numbers must be compatible with Data.Version |
| 2024-09-15 23:41:07 +0200 | troojg | (~troojg@user/troojg) |
| 2024-09-15 23:42:00 +0200 | <monochrom> | I would take the picture as informative rather than normative. The wall of text is the normative one. |
| 2024-09-15 23:42:03 +0200 | <mauke> | Data.Version can definitely represent things that cabal package versions cannot, but I can't tell if it's supposed to be a superset |
| 2024-09-15 23:45:39 +0200 | drlkf | (~drlkf@192.184.163.34.bc.googleusercontent.com) (Quit: drlkf) |
| 2024-09-15 23:46:04 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-15 23:47:23 +0200 | <dolio> | Whoever made the diagram just botched the form of the versions in it. The actual specification just says that certain parts have to be greater than the previous version. It doesn't say the other parts have to stay the same. |
| 2024-09-15 23:48:07 +0200 | <haskellbridge> | <Jade> still not super clear unfortunately |
| 2024-09-15 23:48:11 +0200 | <monochrom> | or must be +1 instead of +314 |
| 2024-09-15 23:48:29 +0200 | <haskellbridge> | <Jade> I'd expect a spec to be rigorous in regards to these things ^^ |
| 2024-09-15 23:49:59 +0200 | neuroevolutus | (~neuroevol@37.19.200.152) (Ping timeout: 256 seconds) |
| 2024-09-15 23:50:08 +0200 | gmg | (~user@user/gehmehgeh) (Quit: Leaving) |
| 2024-09-15 23:50:54 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 260 seconds) |
| 2024-09-15 23:52:54 +0200 | neuroevolutus | (~neuroevol@37.19.200.152) |
| 2024-09-15 23:53:56 +0200 | <monochrom> | Data.Version.Version is meant to be a superset. "a representation which subsumes many of the versioning schemes commonly in use". Fortunately, most versioning schemes use lexicographical ordering, and Data.Version.Version's Ord does that. |
| 2024-09-15 23:54:30 +0200 | <monochrom> | Cabal's is simply the subet where the list length is between 2 and 4. |
| 2024-09-15 23:55:05 +0200 | <mauke> | monochrom: there is no upper limit of 4 |
| 2024-09-15 23:55:25 +0200 | <mauke> | also, the PVP spec only says the components must be "numbers", which is not what Data.Version implements |
| 2024-09-15 23:55:32 +0200 | <monochrom> | PVP mentions Data.Version.Version just for confirming that the Ord instance is good. |
| 2024-09-15 23:55:46 +0200 | <mauke> | that's not a superset, then |
| 2024-09-15 23:56:17 +0200 | <monochrom> | I take Int to be enough for "numbers". |
| 2024-09-15 23:56:39 +0200 | <monochrom> | or rather, "number". |
| 2024-09-15 23:56:39 +0200 | <mauke> | I don't |
| 2024-09-15 23:57:06 +0200 | <monochrom> | OK you want to include quaternions? |
| 2024-09-15 23:57:13 +0200 | <mauke> | what's the minimum value of maxBound::Int? 2^18 or something? |
| 2024-09-15 23:57:26 +0200 | <monochrom> | 2^30 |
| 2024-09-15 23:57:32 +0200 | <monochrom> | err, 2^30 - 1 |
| 2024-09-15 23:57:49 +0200 | <mauke> | right, so I can easily but a 9-digit number in there and break Data.Version, probably silently |
| 2024-09-15 23:57:54 +0200 | <mauke> | s/but/put/ |
| 2024-09-15 23:57:54 +0200 | <monochrom> | err, maybe s/30/29/ |
| 2024-09-15 23:59:27 +0200 | <haskellbridge> | <Jade> -1,25.π.3+2i has got to be one of my favorite versions |
| 2024-09-15 23:59:37 +0200 | <monochrom> | I don't know whether a 9-digit number also breaks Cabal, but you should try and file a bug report. |