| 2026-03-09 00:00:44 +0100 | <davean> | They just add a constrait to solve for to the type checker |
| 2026-03-09 00:03:55 +0100 | picnoir | (~picnoir@about/aquilenet/vodoo/NinjaTrappeur) (Ping timeout: 245 seconds) |
| 2026-03-09 00:06:18 +0100 | Square | (~Square@user/square) (Ping timeout: 244 seconds) |
| 2026-03-09 00:06:23 +0100 | Square2 | (~Square4@user/square) Square |
| 2026-03-09 00:17:20 +0100 | picnoir | (~picnoir@about/aquilenet/vodoo/NinjaTrappeur) NinjaTrappeur |
| 2026-03-09 00:36:51 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-03-09 00:41:42 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 256 seconds) |
| 2026-03-09 00:52:17 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-03-09 00:56:42 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 246 seconds) |
| 2026-03-09 00:57:06 +0100 | stackdroid18 | (~stackdroi@user/stackdroid) () |
| 2026-03-09 01:01:25 +0100 | arandombit | (~arandombi@user/arandombit) (Ping timeout: 268 seconds) |
| 2026-03-09 01:07:58 +0100 | arandombit | (~arandombi@user/arandombit) arandombit |
| 2026-03-09 01:08:03 +0100 | merijn | (~merijn@62.45.136.136) merijn |
| 2026-03-09 01:10:37 +0100 | tremon | (~tremon@83.80.159.219) (Quit: getting boxed in) |
| 2026-03-09 01:12:26 +0100 | merijn | (~merijn@62.45.136.136) (Ping timeout: 244 seconds) |
| 2026-03-09 01:14:12 +0100 | tzh | (~tzh@c-76-115-131-146.hsd1.or.comcast.net) |
| 2026-03-09 01:14:30 +0100 | arandombit | (~arandombi@user/arandombit) (Ping timeout: 244 seconds) |
| 2026-03-09 01:23:29 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-03-09 01:28:02 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 248 seconds) |
| 2026-03-09 01:29:33 +0100 | Tuplanolla | (~Tuplanoll@88.114.89.88) (Quit: Leaving.) |
| 2026-03-09 01:30:16 +0100 | arandombit | (~arandombi@2a02:2455:8656:7100:49f2:4a42:13a7:5052) |
| 2026-03-09 01:30:16 +0100 | arandombit | (~arandombi@2a02:2455:8656:7100:49f2:4a42:13a7:5052) (Changing host) |
| 2026-03-09 01:30:16 +0100 | arandombit | (~arandombi@user/arandombit) arandombit |
| 2026-03-09 01:39:07 +0100 | merijn | (~merijn@62.45.136.136) merijn |
| 2026-03-09 01:40:27 +0100 | arandombit | (~arandombi@user/arandombit) (Remote host closed the connection) |
| 2026-03-09 01:42:33 +0100 | arandombit | (~arandombi@2a02:2455:8656:7100:49f2:4a42:13a7:5052) |
| 2026-03-09 01:42:33 +0100 | arandombit | (~arandombi@2a02:2455:8656:7100:49f2:4a42:13a7:5052) (Changing host) |
| 2026-03-09 01:42:33 +0100 | arandombit | (~arandombi@user/arandombit) arandombit |
| 2026-03-09 01:43:39 +0100 | czan | (~czan@user/mange) czan |
| 2026-03-09 01:43:58 +0100 | xff0x | (~xff0x@2405:6580:b080:900:3d38:9b05:9987:e9b1) (Ping timeout: 268 seconds) |
| 2026-03-09 01:45:54 +0100 | merijn | (~merijn@62.45.136.136) (Ping timeout: 255 seconds) |
| 2026-03-09 01:47:27 +0100 | arandombit | (~arandombi@user/arandombit) (Ping timeout: 246 seconds) |
| 2026-03-09 01:50:49 +0100 | arandombit | (~arandombi@2a02:2455:8656:7100:49f2:4a42:13a7:5052) |
| 2026-03-09 01:50:49 +0100 | arandombit | (~arandombi@2a02:2455:8656:7100:49f2:4a42:13a7:5052) (Changing host) |
| 2026-03-09 01:50:49 +0100 | arandombit | (~arandombi@user/arandombit) arandombit |
| 2026-03-09 01:57:04 +0100 | merijn | (~merijn@62.45.136.136) merijn |
| 2026-03-09 02:02:12 +0100 | merijn | (~merijn@62.45.136.136) (Ping timeout: 264 seconds) |
| 2026-03-09 02:12:22 +0100 | arandombit | (~arandombi@user/arandombit) (Ping timeout: 244 seconds) |
| 2026-03-09 02:12:50 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-03-09 02:12:50 +0100 | karenw_ | (~karenw@user/karenw) (Ping timeout: 248 seconds) |
| 2026-03-09 02:17:49 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 245 seconds) |
| 2026-03-09 02:20:26 +0100 | travgm | (~travgm@fsf/member/travgm) (Quit: Leaving) |
| 2026-03-09 02:20:44 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-03-09 02:25:34 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 265 seconds) |
| 2026-03-09 02:26:29 +0100 | j1n37 | (~j1n37@user/j1n37) j1n37 |
| 2026-03-09 02:36:38 +0100 | merijn | (~merijn@62.45.136.136) merijn |
| 2026-03-09 02:39:06 +0100 | xff0x | (~xff0x@fsb6a9491c.tkyc517.ap.nuro.jp) |
| 2026-03-09 02:40:47 +0100 | merijn | (~merijn@62.45.136.136) (Ping timeout: 244 seconds) |
| 2026-03-09 02:52:00 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-03-09 02:57:19 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 264 seconds) |
| 2026-03-09 03:07:47 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-03-09 03:13:00 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 256 seconds) |
| 2026-03-09 03:23:43 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-03-09 03:30:10 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 245 seconds) |
| 2026-03-09 03:36:10 +0100 | bggd_ | (~bgg@2a01:e0a:fd5:f510:d84e:bd19:3fca:eb64) |
| 2026-03-09 03:43:56 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-03-09 03:48:46 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 276 seconds) |
| 2026-03-09 03:51:39 +0100 | khumba | (~khumba@user/khumba) khumba |
| 2026-03-09 03:56:08 +0100 | <ski> | EvanR : for `class C a b c | a -> b', this expresses `forall a. unique b. exists c. C a b c', which is equivalent to `forall a b0 b1 c0 c1. (C a b0 c0,C a b1 c1) => b0 = b1'. this means that if you infer constraints `C a b0 c0' and `C a b1 c1' then you can add the constraint `b0 = b1'. it also means that if you find two instances where the `a' part is the same (upto renaming of tyvars) but the `b' part |
| 2026-03-09 03:56:14 +0100 | <ski> | differs, then you have a violation of the FD |
| 2026-03-09 03:57:38 +0100 | <ski> | "either this or associated types are needed to make multiparameter type classes typecheck without explicit annotations" -- for many, but not for all, usages. if you only invoke a single `C a b c' constraint (or there's only a single instance), then the presence or absence of the FD makes no difference |
| 2026-03-09 03:59:03 +0100 | <ski> | (by `unique a. ..a..' i here mean "exists at most one", so equivalent to `forall a0 a1. (..a0..,..a1..) => a0 = a1') |
| 2026-03-09 03:59:17 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-03-09 04:03:26 +0100 | arandombit | (~arandombi@user/arandombit) arandombit |
| 2026-03-09 04:04:03 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 255 seconds) |
| 2026-03-09 04:08:06 +0100 | arandombit | (~arandombi@user/arandombit) (Ping timeout: 244 seconds) |
| 2026-03-09 04:09:23 +0100 | arandombit | (~arandombi@2a02:2455:8656:7100:49f2:4a42:13a7:5052) |
| 2026-03-09 04:09:23 +0100 | arandombit | (~arandombi@2a02:2455:8656:7100:49f2:4a42:13a7:5052) (Changing host) |
| 2026-03-09 04:09:23 +0100 | arandombit | (~arandombi@user/arandombit) arandombit |
| 2026-03-09 04:14:26 +0100 | arandombit | (~arandombi@user/arandombit) (Ping timeout: 268 seconds) |
| 2026-03-09 04:14:42 +0100 | myxos | (~myxos@174-18-44-59.tcso.qwest.net) (Remote host closed the connection) |
| 2026-03-09 04:15:02 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-03-09 04:17:38 +0100 | attlin | (~user@user/attlin) (Ping timeout: 248 seconds) |
| 2026-03-09 04:19:45 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 245 seconds) |
| 2026-03-09 04:24:46 +0100 | poscat | (~poscat@user/poscat) (Remote host closed the connection) |
| 2026-03-09 04:26:08 +0100 | myxos | (~myxos@174-18-44-59.tcso.qwest.net) myxokephale |
| 2026-03-09 04:27:40 +0100 | poscat | (~poscat@user/poscat) poscat |
| 2026-03-09 04:37:14 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-03-09 04:38:47 +0100 | <EvanR> | that seems to all add up to the same thing as what i said. None of which to me connects with the "point" which is to select an instance |
| 2026-03-09 04:39:55 +0100 | <EvanR> | the instances form a relation among types, restricted further by the functional dependency noted = all these constraints exist |
| 2026-03-09 04:42:18 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 255 seconds) |
| 2026-03-09 04:47:25 +0100 | attlin | (~user@user/attlin) attlin |
| 2026-03-09 04:50:24 +0100 | peterbecich | (~Thunderbi@71.84.33.135) peterbecich |
| 2026-03-09 04:52:04 +0100 | attlin | (~user@user/attlin) (Quit: Leaving) |
| 2026-03-09 04:53:02 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-03-09 04:56:07 +0100 | attlin | (~user@user/attlin) attlin |
| 2026-03-09 04:57:22 +0100 | rembo10 | (~rembo10@main.remulis.com) (Quit: ZNC 1.10.1 - https://znc.in) |
| 2026-03-09 04:57:55 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 264 seconds) |
| 2026-03-09 04:58:11 +0100 | rembo10 | (~rembo10@main.remulis.com) rembo10 |
| 2026-03-09 04:59:46 +0100 | Square2 | (~Square4@user/square) (Ping timeout: 244 seconds) |
| 2026-03-09 05:14:42 +0100 | khumba | (~khumba@user/khumba) (Ping timeout: 255 seconds) |
| 2026-03-09 05:16:04 +0100 | khumba | (~khumba@24.70.121.49) |
| 2026-03-09 05:16:11 +0100 | khumba | (~khumba@24.70.121.49) (Changing host) |
| 2026-03-09 05:16:11 +0100 | khumba | (~khumba@user/khumba) khumba |
| 2026-03-09 05:18:21 +0100 | tessier | (~tessier@ip68-8-117-219.sd.sd.cox.net) tessier |
| 2026-03-09 05:18:55 +0100 | machinedgod | (~machinedg@d172-219-48-230.abhsia.telus.net) (Ping timeout: 264 seconds) |
| 2026-03-09 05:22:44 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-03-09 05:26:26 +0100 | arandombit | (~arandombi@2a02:2455:8656:7100:49f2:4a42:13a7:5052) |
| 2026-03-09 05:26:26 +0100 | arandombit | (~arandombi@2a02:2455:8656:7100:49f2:4a42:13a7:5052) (Changing host) |
| 2026-03-09 05:26:26 +0100 | arandombit | (~arandombi@user/arandombit) arandombit |
| 2026-03-09 05:29:13 +0100 | khumba | (~khumba@user/khumba) (Ping timeout: 244 seconds) |
| 2026-03-09 05:30:24 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 246 seconds) |
| 2026-03-09 05:31:31 +0100 | arandombit | (~arandombi@user/arandombit) (Ping timeout: 272 seconds) |
| 2026-03-09 05:42:02 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-03-09 05:47:12 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 264 seconds) |
| 2026-03-09 05:57:50 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-03-09 06:00:36 +0100 | arandombit | (~arandombi@user/arandombit) arandombit |
| 2026-03-09 06:02:51 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 255 seconds) |
| 2026-03-09 06:06:03 +0100 | arandombit | (~arandombi@user/arandombit) (Ping timeout: 268 seconds) |
| 2026-03-09 06:12:05 +0100 | arandombit | (~arandombi@user/arandombit) arandombit |
| 2026-03-09 06:13:59 +0100 | merijn | (~merijn@62.45.136.136) merijn |
| 2026-03-09 06:18:18 +0100 | merijn | (~merijn@62.45.136.136) (Ping timeout: 244 seconds) |
| 2026-03-09 06:23:45 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-03-09 06:28:30 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 246 seconds) |
| 2026-03-09 06:32:12 +0100 | jzargo2 | (~jzargo@user/jzargo) (Read error: Connection reset by peer) |
| 2026-03-09 06:32:37 +0100 | jzargo2 | (~jzargo@user/jzargo) jzargo |
| 2026-03-09 06:39:32 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-03-09 06:42:13 +0100 | divlamir | (~divlamir@user/divlamir) (Read error: Connection reset by peer) |
| 2026-03-09 06:42:23 +0100 | divlamir | (~divlamir@user/divlamir) divlamir |
| 2026-03-09 06:44:20 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 245 seconds) |
| 2026-03-09 07:03:55 +0100 | peterbecich | (~Thunderbi@71.84.33.135) (Ping timeout: 264 seconds) |
| 2026-03-09 07:13:25 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-03-09 07:15:39 +0100 | arandombit | (~arandombi@user/arandombit) (Ping timeout: 244 seconds) |
| 2026-03-09 07:18:33 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 272 seconds) |
| 2026-03-09 07:19:27 +0100 | takuan | (~takuan@d8D86B9E9.access.telenet.be) |
| 2026-03-09 07:20:48 +0100 | terrorjack | (~terrorjac@2a01:4f8:271:2d98::2) terrorjack |
| 2026-03-09 07:22:48 +0100 | tzh_ | (~tzh@c-76-115-131-146.hsd1.or.comcast.net) |
| 2026-03-09 07:24:44 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-03-09 07:25:00 +0100 | tzh | (~tzh@c-76-115-131-146.hsd1.or.comcast.net) (Ping timeout: 264 seconds) |
| 2026-03-09 07:29:18 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 268 seconds) |
| 2026-03-09 07:40:07 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-03-09 07:45:20 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 268 seconds) |
| 2026-03-09 07:49:12 +0100 | michalz | (~michalz@185.246.207.200) |
| 2026-03-09 07:49:16 +0100 | oskarw | (~user@user/oskarw) oskarw |
| 2026-03-09 07:50:29 +0100 | sord937 | (~sord937@gateway/tor-sasl/sord937) sord937 |
| 2026-03-09 07:55:54 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-03-09 07:56:35 +0100 | califax_ | (~califax@user/califx) califx |
| 2026-03-09 07:57:41 +0100 | califax | (~califax@user/califx) (Ping timeout: 258 seconds) |
| 2026-03-09 07:57:54 +0100 | califax_ | califax |
| 2026-03-09 08:01:00 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 264 seconds) |
| 2026-03-09 08:10:11 +0100 | Sgeo | (~Sgeo@user/sgeo) (Read error: Connection reset by peer) |
| 2026-03-09 08:11:45 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-03-09 08:12:44 +0100 | arandombit | (~arandombi@user/arandombit) arandombit |
| 2026-03-09 08:12:53 +0100 | czan | (~czan@user/mange) (Quit: Dinner time!) |
| 2026-03-09 08:16:34 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 245 seconds) |
| 2026-03-09 08:17:00 +0100 | arandombit | (~arandombi@user/arandombit) (Ping timeout: 246 seconds) |
| 2026-03-09 08:25:44 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-03-09 08:29:51 +0100 | arandombit | (~arandombi@2a02:2455:8656:7100:49f2:4a42:13a7:5052) |
| 2026-03-09 08:29:51 +0100 | arandombit | (~arandombi@2a02:2455:8656:7100:49f2:4a42:13a7:5052) (Changing host) |
| 2026-03-09 08:29:51 +0100 | arandombit | (~arandombi@user/arandombit) arandombit |
| 2026-03-09 08:30:19 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 245 seconds) |
| 2026-03-09 08:41:08 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-03-09 08:42:52 +0100 | humasect | (~humasect@dyn-192-249-132-90.nexicom.net) (Remote host closed the connection) |
| 2026-03-09 08:47:40 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 245 seconds) |
| 2026-03-09 08:53:33 +0100 | CiaoSen | (~Jura@2a02:8071:64e1:da0:5a47:caff:fe78:33db) CiaoSen |
| 2026-03-09 09:00:56 +0100 | jmcantrell_ | (~weechat@user/jmcantrell) (Ping timeout: 256 seconds) |
| 2026-03-09 09:02:00 +0100 | tzh_ | (~tzh@c-76-115-131-146.hsd1.or.comcast.net) (Quit: zzz) |
| 2026-03-09 09:18:44 +0100 | ft | (~ft@p4fc2a98c.dip0.t-ipconnect.de) (Quit: leaving) |
| 2026-03-09 09:20:18 +0100 | CiaoSen | (~Jura@2a02:8071:64e1:da0:5a47:caff:fe78:33db) (Ping timeout: 268 seconds) |
| 2026-03-09 09:22:31 +0100 | prdak | (~Thunderbi@user/prdak) prdak |
| 2026-03-09 09:25:08 +0100 | prdak | (~Thunderbi@user/prdak) (Remote host closed the connection) |
| 2026-03-09 09:25:38 +0100 | prdak | (~Thunderbi@user/prdak) prdak |
| 2026-03-09 09:29:53 +0100 | merijn | (~merijn@77.242.116.146) merijn |
| 2026-03-09 09:31:59 +0100 | arthurvl | (~arthurvl@2a02-a469-f5e2-1-83d2-ca43-57a2-dc81.fixed6.kpn.net) (Ping timeout: 245 seconds) |
| 2026-03-09 09:37:15 +0100 | arandombit | (~arandombi@user/arandombit) (Ping timeout: 272 seconds) |
| 2026-03-09 09:38:09 +0100 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) (Quit: Laa shay'a waqi'un moutlaq bale kouloun moumkine) |
| 2026-03-09 09:38:26 +0100 | vgtw | (~vgtw@user/vgtw) (Ping timeout: 252 seconds) |
| 2026-03-09 09:41:49 +0100 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) Lord_of_Life |
| 2026-03-09 09:42:00 +0100 | CiaoSen | (~Jura@2a02:8071:64e1:da0:5a47:caff:fe78:33db) CiaoSen |
| 2026-03-09 09:45:45 +0100 | akegalj | (~akegalj@246-221.dsl.iskon.hr) akegalj |
| 2026-03-09 09:46:23 +0100 | emmanuelux | (~em@user/emmanuelux) (Quit: bye) |
| 2026-03-09 09:49:48 +0100 | chele | (~chele@user/chele) chele |
| 2026-03-09 09:52:18 +0100 | chexum | (~quassel@gateway/tor-sasl/chexum) (Remote host closed the connection) |
| 2026-03-09 09:52:21 +0100 | arandombit | (~arandombi@2a02:2455:8656:7100:49f2:4a42:13a7:5052) |
| 2026-03-09 09:52:21 +0100 | arandombit | (~arandombi@2a02:2455:8656:7100:49f2:4a42:13a7:5052) (Changing host) |
| 2026-03-09 09:52:21 +0100 | arandombit | (~arandombi@user/arandombit) arandombit |
| 2026-03-09 09:52:40 +0100 | chexum | (~quassel@gateway/tor-sasl/chexum) chexum |
| 2026-03-09 09:55:40 +0100 | castan | (~castan@2a02:2f0f:8210:d800:1625:20a6:66c:b041) |
| 2026-03-09 09:57:31 +0100 | __monty__ | (~toonn@user/toonn) toonn |
| 2026-03-09 10:01:50 +0100 | <castan> | Hi. Can someone help me understand what sorcery makes `mappend mempty Sum 3` get parsed as `mappend mempty (Sum 3)` |
| 2026-03-09 10:02:24 +0100 | czan | (~czan@user/mange) czan |
| 2026-03-09 10:03:08 +0100 | loungerry_ | (~loungerry@150.241.86.78) (Remote host closed the connection) |
| 2026-03-09 10:04:35 +0100 | <probie> | None |
| 2026-03-09 10:04:42 +0100 | <Leary> | castan: It doesn't get /parsed/ as that; that's what it equals. `mappend mempty x = x` ==> `mappend mempty Sum = Sum` ==> `mappend mempty Sum 3 = Sum 3`. |
| 2026-03-09 10:05:04 +0100 | <Leary> | One key detail here being `Monoid b => Monoid (a -> b)`. |
| 2026-03-09 10:05:21 +0100 | <probie> | :t mappend mempty Sum |
| 2026-03-09 10:05:22 +0100 | <lambdabot> | Num a => a -> Sum a |
| 2026-03-09 10:05:38 +0100 | <probie> | :t (mappend mempty) |
| 2026-03-09 10:05:39 +0100 | <lambdabot> | Monoid a => a -> a |
| 2026-03-09 10:05:42 +0100 | <castan> | Oh hahahha |
| 2026-03-09 10:06:35 +0100 | <castan> | I see now, thank you |
| 2026-03-09 10:07:58 +0100 | <mesaoptimizer> | :t mappend |
| 2026-03-09 10:07:59 +0100 | <lambdabot> | Monoid a => a -> a -> a |
| 2026-03-09 10:08:06 +0100 | <mesaoptimizer> | :t mappend mempty |
| 2026-03-09 10:08:07 +0100 | <lambdabot> | Monoid a => a -> a |
| 2026-03-09 10:08:14 +0100 | <mesaoptimizer> | :t mappend mempty Sum |
| 2026-03-09 10:08:15 +0100 | <lambdabot> | Num a => a -> Sum a |
| 2026-03-09 10:08:21 +0100 | <mesaoptimizer> | :t mappend mempty Sum 3 |
| 2026-03-09 10:08:22 +0100 | <lambdabot> | Num t => Sum t |
| 2026-03-09 10:10:19 +0100 | <__monty__> | Were you expecting a different result? Because `mappend mempty (Sum 3) = Sum 3` too. |
| 2026-03-09 10:10:20 +0100 | <merijn> | best monoit instance ever |
| 2026-03-09 10:10:40 +0100 | <merijn> | __monty__: No, his question is why is it correct at all :p |
| 2026-03-09 10:10:58 +0100 | <merijn> | __monty__: Which, if you don't realise the monoid on functions is confusing |
| 2026-03-09 10:12:02 +0100 | <merijn> | castan: And absolutely brilliant use for this monoid is the fact that Ordering is a monoid, so you can use it to combine comparison functions to do multi way ordering |
| 2026-03-09 10:13:07 +0100 | <merijn> | :t comparing |
| 2026-03-09 10:13:08 +0100 | <lambdabot> | Ord a => (b -> a) -> b -> b -> Ordering |
| 2026-03-09 10:13:13 +0100 | <merijn> | :t sortBy |
| 2026-03-09 10:13:14 +0100 | <lambdabot> | (a -> a -> Ordering) -> [a] -> [a] |
| 2026-03-09 10:14:00 +0100 | <merijn> | > sortBy (comparing snd <> comparing fst) [(3,9), (2,9), (1, 9), (3, 1), (2, 1), (1,1)] |
| 2026-03-09 10:14:02 +0100 | <lambdabot> | [(1,1),(2,1),(3,1),(1,9),(2,9),(3,9)] |
| 2026-03-09 10:14:12 +0100 | <merijn> | Magic |
| 2026-03-09 10:15:17 +0100 | <probie> | > sortBy (comparing snd <> comparing (flip mod 2 . fst) <> comparing fst) [(3,9), (2,9), (1, 9), (3, 1), (2, 1), (1,1)] |
| 2026-03-09 10:15:18 +0100 | <lambdabot> | [(2,1),(1,1),(3,1),(2,9),(1,9),(3,9)] |
| 2026-03-09 10:15:55 +0100 | <castan> | that's wild, I need to play with it for a bit to understand how |
| 2026-03-09 10:16:46 +0100 | <merijn> | Holy moly is Hackage being DOSed or something? |
| 2026-03-09 10:16:49 +0100 | <merijn> | It's slow as sin |
| 2026-03-09 10:17:17 +0100 | <merijn> | > sortBy (comparing snd <> comparing (Down . fst)) [(3,9), (2,9), (1, 9), (3, 1), (2, 1), (1,1)] |
| 2026-03-09 10:17:19 +0100 | <lambdabot> | [(3,1),(2,1),(1,1),(3,9),(2,9),(1,9)] |
| 2026-03-09 10:17:24 +0100 | <merijn> | Even funkier with newtypes like Down :p |
| 2026-03-09 10:17:37 +0100 | fp | (~Thunderbi@staff235.kora-dyn.aalto.fi) fp |
| 2026-03-09 10:18:04 +0100 | fp | (~Thunderbi@staff235.kora-dyn.aalto.fi) (Client Quit) |
| 2026-03-09 10:18:08 +0100 | <merijn> | castan: Basically the monoid on functions is "if the final result is a monoid, then simply pass each argument to both functions and mappend the result" |
| 2026-03-09 10:18:25 +0100 | fp | (~Thunderbi@2001:708:20:1406::1370) fp |
| 2026-03-09 10:18:48 +0100 | <merijn> | castan: "instance Monoid b => Monoid (a -> b) where mappend f g = \x -> mappend (f x) (g x)" |
| 2026-03-09 10:19:36 +0100 | <merijn> | castan: But that instance applies recursively (i.e. since "a -> b" is a Monoid when 'b' is, then "c -> a -> b" (which is just "c -> (a -> b)" is also a monoid) |
| 2026-03-09 10:20:06 +0100 | <merijn> | :t comparing fst |
| 2026-03-09 10:20:07 +0100 | <lambdabot> | Ord a => (a, b) -> (a, b) -> Ordering |
| 2026-03-09 10:20:11 +0100 | <merijn> | :t comparing snd |
| 2026-03-09 10:20:12 +0100 | <lambdabot> | Ord a1 => (a2, a1) -> (a2, a1) -> Ordering |
| 2026-03-09 10:21:55 +0100 | <merijn> | Ordering is just "data Ordering = LT | EQ | GT" with "mappend LT _ = LT; mappend GT _ = GT; mappend EQ x = x" (i.e. it gives you the left-most non-equal value) |
| 2026-03-09 10:22:57 +0100 | <merijn> | So "comparing snd <> comparing fst" passes the same 2 tuples to both functions and mappend results, which simply returns the result of "comparing snd" **unless** that returns EQ, then it falls back to the result of "comparing fst" |
| 2026-03-09 10:23:30 +0100 | <castan> | oh and then with <> you get a lexicographic order on the pairs |
| 2026-03-09 10:23:56 +0100 | <merijn> | castan: lexicographic order on the whatever functions you pass to it |
| 2026-03-09 10:24:04 +0100 | <merijn> | but yes |
| 2026-03-09 10:24:35 +0100 | <castan> | this is really cool, thank you for the info |
| 2026-03-09 10:24:53 +0100 | <merijn> | It's stupid powerful for trivially writing really complicated sorts |
| 2026-03-09 10:25:56 +0100 | <merijn> | It also works well for stuff like aggregating data, since you just need a monoid on the final result and then you can compose any number of functions computing stuff that take the same arguments into bigger aggregations |
| 2026-03-09 10:26:42 +0100 | <merijn> | castan: It's even neater since you can my personal favourite "mwhen :: Monoid b => Boolean -> b" to selectively disable parts of aggregation/sorting |
| 2026-03-09 10:27:55 +0100 | castan | (~castan@2a02:2f0f:8210:d800:1625:20a6:66c:b041) (Quit: castan) |
| 2026-03-09 10:29:23 +0100 | <merijn> | For a non-trivial real world example of the power of just stacking a bunch of monoids, see: https://github.com/haskell/cabal/blob/master/Cabal/src/Distribution/Simple/Program/GHC.hs#L67-L144 |
| 2026-03-09 10:30:06 +0100 | <merijn> | Good to see that that code hasn't been maintained/updated for, like, 10 GHC releases now >.> |
| 2026-03-09 10:34:53 +0100 | prdak | (~Thunderbi@user/prdak) (Ping timeout: 272 seconds) |
| 2026-03-09 10:37:49 +0100 | <[exa]> | is there a "strict" generic monoidal `fold` ? |
| 2026-03-09 10:38:11 +0100 | <[exa]> | the docs recommend going for `foldMap' id` but that's not cute |
| 2026-03-09 10:38:17 +0100 | <[exa]> | y no fold' |
| 2026-03-09 10:38:55 +0100 | <[exa]> | merijn: btw the slow hackage situation has been dragging for over a week now I'd say. can we somehow throw servers at it? |
| 2026-03-09 10:39:42 +0100 | kuribas | (~user@2a02-1810-2825-6000-46e-614f-97bf-a1c6.ip6.access.telenet.be) kuribas |
| 2026-03-09 10:40:28 +0100 | <kuribas> | Is a lot of haskell code now also "vibecoded"? |
| 2026-03-09 10:40:33 +0100 | <kuribas> | I noticed this PR: https://github.com/winterland1989/mysql-haskell/pull/72 |
| 2026-03-09 10:40:56 +0100 | <kuribas> | "Generated with Claude Code" |
| 2026-03-09 10:42:48 +0100 | prdak | (~Thunderbi@user/prdak) prdak |
| 2026-03-09 10:43:12 +0100 | akegalj | (~akegalj@246-221.dsl.iskon.hr) (Quit: leaving) |
| 2026-03-09 10:43:39 +0100 | <[exa]> | kuribas: apparently even some haskell folks love to just pour code on stuff |
| 2026-03-09 10:44:14 +0100 | <kuribas> | "catch (void (waitCommandReply tlsIs')) ((\ _ -> return ()) :: SomeException -> IO ())" |
| 2026-03-09 10:45:01 +0100 | <[exa]> | it's for mysql so aesthetics arguments don't apply |
| 2026-03-09 10:45:22 +0100 | <kuribas> | right :) |
| 2026-03-09 10:45:38 +0100 | <kuribas> | Also "if isOK q then return () else decodeFromPacket q >>= throwIO . ERRException" |
| 2026-03-09 10:45:47 +0100 | <kuribas> | Instead "unless (isOk q) $ ..." |
| 2026-03-09 10:46:02 +0100 | <[exa]> | c'mon it's python encoded in haskell, newbie-friendly! |
| 2026-03-09 10:46:07 +0100 | <mesaoptimizer> | lol |
| 2026-03-09 10:46:34 +0100 | alinab | (sid468903@id-468903.helmsley.irccloud.com) (Quit: Connection closed for inactivity) |
| 2026-03-09 10:47:04 +0100 | <[exa]> | I found that particular issue to be an interesting thing to write into homework assignments |
| 2026-03-09 10:48:15 +0100 | <[exa]> | if you explicitly say "do not use Bool", humans will switch to some correct-by-construction workflow (like having Maybe query or so); poor claude will encode booleans in strings and integers |
| 2026-03-09 10:51:04 +0100 | <mesaoptimizer> | I wonder if there are languages that are extremely resistant to LLM codegen, such that any code written is very likely human-written |
| 2026-03-09 10:51:52 +0100 | <kuribas> | idris? |
| 2026-03-09 10:53:02 +0100 | <mesaoptimizer> | possibly, yeah. I do notice that it is incredibly difficult for LLMs to write dependent type theoretic code, but my experiments were only with Agda (when attempting to learn it) |
| 2026-03-09 10:53:38 +0100 | <mesaoptimizer> | one could also make syntax-semantics combinations that are extremely alien to the LLM |
| 2026-03-09 10:54:19 +0100 | <mesaoptimizer> | perhaps if you model the syntax-semantics space, you can essentially sample from regions that are adverserially optimized to be incoherent and counter-intuitive to the model |
| 2026-03-09 10:54:59 +0100 | <mesaoptimizer> | (question is whether they will stay intuitive enough for programmers) |
| 2026-03-09 11:25:45 +0100 | xff0x | (~xff0x@fsb6a9491c.tkyc517.ap.nuro.jp) (Ping timeout: 248 seconds) |
| 2026-03-09 11:28:49 +0100 | vgtw | (~vgtw@user/vgtw) vgtw |
| 2026-03-09 11:29:07 +0100 | <merijn> | [exa]: tbh, chatgpt seems to do much better with strongly typed code than other stuff imo |
| 2026-03-09 11:32:10 +0100 | <newmind> | merijn: i feel like it is quite a bit worse at generation, it one-shots less reliably, and often falls back to imperative patterns which don't quite fit wit haskell... but at least most of the time it then doesn't compile and it can fix that, rather than relying just on unit tests or the user catching it |
| 2026-03-09 11:33:45 +0100 | <merijn> | newmind: I've mostly been using it with Scala, so not entirely sure how it does for HAskell |
| 2026-03-09 11:34:03 +0100 | <merijn> | mesaoptimizer: I mean, that's just reinventing Epigram but unprincipled :p\ |
| 2026-03-09 11:35:18 +0100 | <newmind> | at least the claude models are.. usable? they still get a lot of it wrong, and often get stuck in trivial sections, and the code they produce is... quite bad... but it compiles, and once it's working, refactoring it in a strongly typed language is so much more reliable than without |
| 2026-03-09 11:41:58 +0100 | dutchie | (~dutchie@user/dutchie) (Remote host closed the connection) |
| 2026-03-09 11:42:41 +0100 | dutchie | (~dutchie@user/dutchie) dutchie |
| 2026-03-09 11:48:42 +0100 | arthurvl | (~arthurvl@2a02-a469-f5e2-1-83d2-ca43-57a2-dc81.fixed6.kpn.net) earthy |
| 2026-03-09 11:59:05 +0100 | j1n37 | (~j1n37@user/j1n37) (Read error: Connection reset by peer) |
| 2026-03-09 12:00:19 +0100 | j1n37 | (~j1n37@user/j1n37) j1n37 |
| 2026-03-09 12:18:47 +0100 | <int-e> | "but it compiles" -- yeah because they throw the code at the compiler until it does |
| 2026-03-09 12:19:57 +0100 | <newmind> | int-e: more or less, yes :) still more successful than just inventing code that then just crashes at runtime |
| 2026-03-09 12:20:02 +0100 | <mauke> | I strongly prefer code to be typed, not generated |
| 2026-03-09 12:20:14 +0100 | dutchie | (~dutchie@user/dutchie) (Remote host closed the connection) |
| 2026-03-09 12:20:28 +0100 | <int-e> | mauke: with Haskell you can have both! |
| 2026-03-09 12:20:30 +0100 | int-e | runs |
| 2026-03-09 12:20:33 +0100 | prdak | (~Thunderbi@user/prdak) (Ping timeout: 265 seconds) |
| 2026-03-09 12:21:14 +0100 | dutchie | (~dutchie@user/dutchie) dutchie |
| 2026-03-09 12:21:50 +0100 | dhil | (~dhil@5.151.29.139) dhil |
| 2026-03-09 12:28:07 +0100 | prdak | (~Thunderbi@user/prdak) prdak |
| 2026-03-09 12:29:11 +0100 | danza | (~danza@user/danza) danza |
| 2026-03-09 12:37:13 +0100 | _d0t | (~{-d0t-}@user/-d0t-/x-7915216) (Ping timeout: 276 seconds) |
| 2026-03-09 12:42:20 +0100 | _d0t | (~{-d0t-}@user/-d0t-/x-7915216) {-d0t-} |
| 2026-03-09 12:45:01 +0100 | oskarw | (~user@user/oskarw) (Ping timeout: 276 seconds) |
| 2026-03-09 12:50:58 +0100 | danza | (~danza@user/danza) (Read error: Connection reset by peer) |
| 2026-03-09 12:51:12 +0100 | danza | (~danza@user/danza) danza |
| 2026-03-09 12:52:02 +0100 | danza | (~danza@user/danza) (Remote host closed the connection) |
| 2026-03-09 12:54:20 +0100 | CiaoSen | (~Jura@2a02:8071:64e1:da0:5a47:caff:fe78:33db) (Ping timeout: 245 seconds) |
| 2026-03-09 12:56:18 +0100 | wootehfoot | (~wootehfoo@user/wootehfoot) wootehfoot |
| 2026-03-09 12:57:17 +0100 | target_i | (~target_i@user/target-i/x-6023099) target_i |
| 2026-03-09 13:05:24 +0100 | czan | (~czan@user/mange) (Ping timeout: 246 seconds) |
| 2026-03-09 13:06:12 +0100 | CiaoSen | (~Jura@2a02:8071:64e1:da0:5a47:caff:fe78:33db) CiaoSen |
| 2026-03-09 13:09:56 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Quit: = "") |
| 2026-03-09 13:24:29 +0100 | xff0x | (~xff0x@2405:6580:b080:900:3f2f:c15f:718f:76d4) |
| 2026-03-09 13:25:46 +0100 | <ski> | EvanR : yea, the point of that respone was to provide perhaps a more mathematical/logical aspect to the FD semantics. but yes, neither of the mentioned two effects have anything to do with actually selecting an instance, but rather to constrain the usage (merging used instances (demanded constraints)) and definition (disallowing instances violating the FD) of instances |
| 2026-03-09 13:31:24 +0100 | YoungFrog | (~youngfrog@39.129-180-91.adsl-dyn.isp.belgacom.be) (Quit: ZNC 1.7.x-git-3-96481995 - https://znc.in) |
| 2026-03-09 13:32:41 +0100 | YoungFrog | (~youngfrog@2a02:a03f:ca07:f900:1032:66d2:1281:f541) youngfrog |
| 2026-03-09 13:46:32 +0100 | Square2 | (~Square4@user/square) Square |
| 2026-03-09 13:54:06 +0100 | prdak | (~Thunderbi@user/prdak) (Read error: Connection reset by peer) |
| 2026-03-09 13:54:17 +0100 | prdak1 | (~Thunderbi@user/prdak) prdak |
| 2026-03-09 13:58:29 +0100 | prdak1 | prdak |
| 2026-03-09 14:13:34 +0100 | wootehfoot | (~wootehfoo@user/wootehfoot) (Read error: Connection reset by peer) |
| 2026-03-09 14:16:17 +0100 | Fischmiep | (~Fischmiep@user/Fischmiep) (Remote host closed the connection) |
| 2026-03-09 14:26:07 +0100 | oskarw | (~user@user/oskarw) oskarw |
| 2026-03-09 14:35:59 +0100 | st_aldini | (~Betterbir@136.48.46.187) (Quit: st_aldini) |
| 2026-03-09 14:54:05 +0100 | comerijn | (~merijn@77.242.116.146) merijn |
| 2026-03-09 14:57:00 +0100 | merijn | (~merijn@77.242.116.146) (Ping timeout: 268 seconds) |
| 2026-03-09 15:01:49 +0100 | ezzieyguywuf | (~Unknown@user/ezzieyguywuf) ezzieyguywuf |
| 2026-03-09 15:09:00 +0100 | aka_dude | (~aka_dude@2a03:f80:30:f490::1) (Quit: Gateway shutdown) |
| 2026-03-09 15:10:10 +0100 | aka_dude | (~aka_dude@2a03:f80:30:f490::1) |
| 2026-03-09 15:11:56 +0100 | danza | (~danza@user/danza) danza |
| 2026-03-09 15:26:12 +0100 | arandombit | (~arandombi@user/arandombit) (Ping timeout: 264 seconds) |
| 2026-03-09 15:27:48 +0100 | arandombit | (~arandombi@2a02:2455:8656:7100:2149:c35e:cd23:4e9a) |
| 2026-03-09 15:27:48 +0100 | arandombit | (~arandombi@2a02:2455:8656:7100:2149:c35e:cd23:4e9a) (Changing host) |
| 2026-03-09 15:27:48 +0100 | arandombit | (~arandombi@user/arandombit) arandombit |
| 2026-03-09 15:48:30 +0100 | Digit | (~user@user/digit) (Ping timeout: 245 seconds) |
| 2026-03-09 15:48:53 +0100 | Digitteknohippie | (~user@user/digit) Digit |
| 2026-03-09 15:57:44 +0100 | danza | (~danza@user/danza) (Remote host closed the connection) |
| 2026-03-09 16:02:12 +0100 | machinedgod | (~machinedg@d172-219-48-230.abhsia.telus.net) machinedgod |
| 2026-03-09 16:10:24 +0100 | arandombit | (~arandombi@user/arandombit) (Ping timeout: 244 seconds) |
| 2026-03-09 16:18:22 +0100 | loonycyborg | (~loonycybo@wesnoth/developer/loonycyborg) (Quit: ZNC - http://znc.sourceforge.net) |
| 2026-03-09 16:22:13 +0100 | systemhalted | (~systemhal@108.147.100.161) systemhalted |
| 2026-03-09 16:22:54 +0100 | peterbecich | (~Thunderbi@71.84.33.135) peterbecich |
| 2026-03-09 16:23:35 +0100 | systemhalted | (~systemhal@108.147.100.161) (Remote host closed the connection) |
| 2026-03-09 16:24:20 +0100 | Digitteknohippie | (~user@user/digit) (Ping timeout: 268 seconds) |
| 2026-03-09 16:27:35 +0100 | tremon | (~tremon@83.80.159.219) tremon |
| 2026-03-09 16:37:00 +0100 | Fischmiep | (~Fischmiep@user/Fischmiep) Fischmiep |
| 2026-03-09 16:40:18 +0100 | pabs3 | (~pabs3@user/pabs3) (Ping timeout: 246 seconds) |
| 2026-03-09 16:48:14 +0100 | CiaoSen | (~Jura@2a02:8071:64e1:da0:5a47:caff:fe78:33db) (Ping timeout: 245 seconds) |
| 2026-03-09 16:52:12 +0100 | j1n37 | (~j1n37@user/j1n37) (Ping timeout: 255 seconds) |
| 2026-03-09 16:53:51 +0100 | pabs3 | (~pabs3@user/pabs3) pabs3 |
| 2026-03-09 16:58:32 +0100 | jmcantrell_ | (~weechat@user/jmcantrell) jmcantrell |
| 2026-03-09 17:03:04 +0100 | fp | (~Thunderbi@2001:708:20:1406::1370) (Ping timeout: 276 seconds) |
| 2026-03-09 17:08:04 +0100 | <[exa]> | is there any reason why `toList` could not serve as a sufficient minimal definition of Foldable? |
| 2026-03-09 17:09:37 +0100 | <[exa]> | (somewhat stupidly I assumeth and debuggeth) |
| 2026-03-09 17:10:02 +0100 | <mesaoptimizer> | :t toList |
| 2026-03-09 17:10:03 +0100 | <lambdabot> | Foldable t => t a -> [a] |
| 2026-03-09 17:11:35 +0100 | ezzieyguywuf | (~Unknown@user/ezzieyguywuf) () |
| 2026-03-09 17:14:12 +0100 | prdak | (~Thunderbi@user/prdak) (Ping timeout: 264 seconds) |
| 2026-03-09 17:14:52 +0100 | pavonia | (~user@user/siracusa) (Quit: Bye!) |
| 2026-03-09 17:15:44 +0100 | Digit | (~user@user/digit) Digit |
| 2026-03-09 17:16:00 +0100 | vgtw | (~vgtw@user/vgtw) (Ping timeout: 246 seconds) |
| 2026-03-09 17:16:30 +0100 | <dolio> | [exa]: I think the obstacle is how default definitions work. You can only give one default definition for each method, and those determine the minimal definitions. |
| 2026-03-09 17:16:31 +0100 | <[exa]> | (oh ok I guess because the defaults would be a mess) |
| 2026-03-09 17:16:54 +0100 | <[exa]> | yeah I assume that if we could default from 3 different ones, the 2 would need to pick which one to default from |
| 2026-03-09 17:16:59 +0100 | <[exa]> | or make a 3-cycle of them all |
| 2026-03-09 17:17:01 +0100 | <[exa]> | wild |
| 2026-03-09 17:18:07 +0100 | <dolio> | You could make a cycle betwee foldMap, foldr and toList. But that might make some choices of minimal implementation kind of bad. |
| 2026-03-09 17:18:58 +0100 | <[exa]> | yeah I myself already have 2 different correct opinions on which direction of the cycle is more correct... imagine giving it to more people :) |
| 2026-03-09 17:22:59 +0100 | Digit | Digitteknohippie |
| 2026-03-09 17:23:26 +0100 | vgtw | (~vgtw@user/vgtw) vgtw |
| 2026-03-09 17:23:46 +0100 | Digitteknohippie | Digit |
| 2026-03-09 17:29:48 +0100 | peterbecich | (~Thunderbi@71.84.33.135) (Ping timeout: 264 seconds) |
| 2026-03-09 17:34:49 +0100 | kuribas | (~user@2a02-1810-2825-6000-46e-614f-97bf-a1c6.ip6.access.telenet.be) (Ping timeout: 248 seconds) |
| 2026-03-09 17:36:24 +0100 | bggd_ | (~bgg@2a01:e0a:fd5:f510:d84e:bd19:3fca:eb64) (Remote host closed the connection) |
| 2026-03-09 17:37:00 +0100 | vgtw | (~vgtw@user/vgtw) (Ping timeout: 246 seconds) |
| 2026-03-09 17:37:26 +0100 | vgtw | (~vgtw@user/vgtw) vgtw |
| 2026-03-09 17:40:49 +0100 | oats | (~oats@user/oats) (Read error: Connection reset by peer) |
| 2026-03-09 17:41:04 +0100 | oats | (~oats@user/oats) oats |
| 2026-03-09 17:43:55 +0100 | infinity0 | (~infinity0@pwned.gg) (Ping timeout: 245 seconds) |
| 2026-03-09 17:53:34 +0100 | kuribas | (~user@2a02-1810-2825-6000-414c-630a-ac36-9026.ip6.access.telenet.be) kuribas |
| 2026-03-09 17:58:56 +0100 | kimiamania4 | (~b4b260c9@user/kimiamania) (Quit: PegeLinux) |
| 2026-03-09 18:00:03 +0100 | kimiamania4 | (~b4b260c9@user/kimiamania) kimiamania |
| 2026-03-09 18:04:22 +0100 | infinity0 | (~infinity0@pwned.gg) infinity0 |
| 2026-03-09 18:06:24 +0100 | AlexNoo | (~AlexNoo@178.34.160.184) |
| 2026-03-09 18:07:09 +0100 | AlexNoo_ | (~AlexNoo@178.34.160.184) |
| 2026-03-09 18:07:52 +0100 | AlexNoo__ | (~AlexNoo@178.34.160.184) |
| 2026-03-09 18:10:00 +0100 | comerijn | (~merijn@77.242.116.146) (Ping timeout: 265 seconds) |
| 2026-03-09 18:10:36 +0100 | AlexNoo | (~AlexNoo@178.34.160.184) (Ping timeout: 246 seconds) |
| 2026-03-09 18:10:58 +0100 | AlexNoo | (~AlexNoo@178.34.160.184) |
| 2026-03-09 18:11:18 +0100 | AlexNoo_ | (~AlexNoo@178.34.160.184) (Ping timeout: 246 seconds) |
| 2026-03-09 18:12:00 +0100 | AlexNoo__ | (~AlexNoo@178.34.160.184) (Ping timeout: 246 seconds) |
| 2026-03-09 18:24:01 +0100 | <tccq> | what is the correct state variable s to use for STArray? I want to have some monadic stuff over a large array of ints and a record of some other info (to make a stack machine) |
| 2026-03-09 18:24:18 +0100 | <tccq> | not sure I understand how STArray and regular ST fit together |
| 2026-03-09 18:25:24 +0100 | <mauke> | s |
| 2026-03-09 18:25:49 +0100 | <mauke> | for ST to work, you have to leave s generic |
| 2026-03-09 18:26:23 +0100 | <mauke> | well, and it has to match all the other 's's of the ST context and all the variables used in that context |
| 2026-03-09 18:27:01 +0100 | <[exa]> | tccq: `s` is voidy like RealWorld but without RealWorld |
| 2026-03-09 18:27:36 +0100 | raincomplex | (~rain@user/raincomplex) (Read error: Connection reset by peer) |
| 2026-03-09 18:28:02 +0100 | <[exa]> | tccq: as a minor annoyance, if you want to type stuff correctly you might need higher-rank types with a (forall s. ...) somewhere |
| 2026-03-09 18:29:14 +0100 | raincomplex | (~rain@pool-173-54-183-192.nwrknj.fios.verizon.net) |
| 2026-03-09 18:29:14 +0100 | raincomplex | (~rain@pool-173-54-183-192.nwrknj.fios.verizon.net) (Changing host) |
| 2026-03-09 18:29:14 +0100 | raincomplex | (~rain@user/raincomplex) raincomplex |
| 2026-03-09 18:31:49 +0100 | <tccq> | hmm ok |
| 2026-03-09 18:32:22 +0100 | <tccq> | if I want my mutable array and a regular state var should I have two nested ST's then? One generic s for the array and one with my Info struct? |
| 2026-03-09 18:32:36 +0100 | <mauke> | no, you can use the same s for both |
| 2026-03-09 18:33:53 +0100 | <tccq> | something like `type MemM a = (STArray RegInfo) Int Slot (ST RegInfo) a`? |
| 2026-03-09 18:34:09 +0100 | <tccq> | use get/put for RegInfo and read/writeArray for the array? |
| 2026-03-09 18:34:16 +0100 | <[exa]> | tccq: the "state" there is more of a token that doesn't really carry anything |
| 2026-03-09 18:34:51 +0100 | <mauke> | that doesn't look like s |
| 2026-03-09 18:35:39 +0100 | <mauke> | you don't get to choose an s |
| 2026-03-09 18:35:41 +0100 | <mauke> | :t runST |
| 2026-03-09 18:35:42 +0100 | <lambdabot> | (forall s. ST s a) -> a |
| 2026-03-09 18:35:42 +0100 | <[exa]> | tccq: more like `type MemM s a = STArray s Int Slot` |
| 2026-03-09 18:35:46 +0100 | <mauke> | ^ this fella does |
| 2026-03-09 18:36:09 +0100 | <mauke> | :t runSTArray |
| 2026-03-09 18:36:09 +0100 | <[exa]> | tccq: (not sure what RegInfo is) |
| 2026-03-09 18:36:10 +0100 | <lambdabot> | error: [GHC-88464] |
| 2026-03-09 18:36:10 +0100 | <lambdabot> | Variable not in scope: runSTArray |
| 2026-03-09 18:36:33 +0100 | <tccq> | RegInfo is just a big record if ints and stuff |
| 2026-03-09 18:36:41 +0100 | <tccq> | like I said I'm trying to make a little stack machine |
| 2026-03-09 18:37:29 +0100 | <tccq> | I understand s is scoped so that the state can't escape, but I want to use it at some specific type right? |
| 2026-03-09 18:37:35 +0100 | <mauke> | no |
| 2026-03-09 18:37:38 +0100 | <mauke> | never |
| 2026-03-09 18:37:50 +0100 | <mauke> | the "state" is not your data |
| 2026-03-09 18:38:05 +0100 | <[exa]> | tccq: ahh so reginfo is the actual state that you want to hold, together with the array |
| 2026-03-09 18:38:09 +0100 | <tccq> | eys |
| 2026-03-09 18:38:38 +0100 | <tccq> | I could write all of this by passing an array and this record to every function |
| 2026-03-09 18:38:39 +0100 | <[exa]> | tccq: in short, you don't need to carry these in the type -- you make arrays like you would with mutable vectors in IO. These are "carried through" but only implicitly. |
| 2026-03-09 18:38:53 +0100 | <tccq> | but I don't want to do that and hint to the compiler that there is only ever one array |
| 2026-03-09 18:39:15 +0100 | <mauke> | that sounds more like State, not ST |
| 2026-03-09 18:39:27 +0100 | <[exa]> | yes, State or Reader (ok for mutables) over the ST |
| 2026-03-09 18:39:27 +0100 | <tccq> | possibly, not sure I understand the difference |
| 2026-03-09 18:39:29 +0100 | <mauke> | or maybe Reader |
| 2026-03-09 18:39:56 +0100 | <EvanR> | an ST program can create mutable variables and arrays for use within its scope |
| 2026-03-09 18:40:07 +0100 | <EvanR> | State only has 1 "mutable" variable |
| 2026-03-09 18:40:13 +0100 | <EvanR> | accessed using get and put |
| 2026-03-09 18:40:23 +0100 | <[exa]> | tccq: the point is that the type `s` there only serves the ordering of operations. Your array is indexed by the `s` for (among other) the purpose that it's hard to get it out of the execution of runST that uses some concrete `s` (that you don't know) |
| 2026-03-09 18:40:32 +0100 | <mauke> | Reader is roughly equivalent to function arguments: it takes care of passing a "context value" around |
| 2026-03-09 18:41:01 +0100 | <mauke> | State emulates a single mutable value (by secretly taking an extra argument and returning an extra value, the "updated" value) |
| 2026-03-09 18:41:47 +0100 | <mauke> | ST is an execution environment that provides genuine mutable variables (and arrays), which you can allocate/read/write within the ST context. the catch is that all variables are "local": you must return a pure result |
| 2026-03-09 18:41:58 +0100 | tzh | (~tzh@c-76-115-131-146.hsd1.or.comcast.net) tzh |
| 2026-03-09 18:42:04 +0100 | <EvanR> | just give me a tall State and a do notation to steer her by |
| 2026-03-09 18:42:19 +0100 | <mauke> | ST is meant for situations where you want to use imperative features internally, but your public interface is still pure |
| 2026-03-09 18:42:46 +0100 | <[exa]> | tccq: ...so I guess: type MemM s a = StateT (RegInfo, STArray s Int Slot) (St s) a |
| 2026-03-09 18:43:07 +0100 | <tccq> | yea ok so the other question is which order to layer them in |
| 2026-03-09 18:43:07 +0100 | <[exa]> | might be faster as ReaderT if you can store RegInfo behind some kind of ST reference (TVar ?) |
| 2026-03-09 18:43:13 +0100 | <tccq> | I think normally I want to update both most of the time |
| 2026-03-09 18:43:17 +0100 | <tccq> | so maybe it doesn't matter? |
| 2026-03-09 18:43:51 +0100 | <[exa]> | yeah if you want the _values_ in State, you don't need `ST` btw |
| 2026-03-09 18:43:54 +0100 | <tccq> | cause the STArray also takes a monad to sequence with right? and that could be my State RegInfo |
| 2026-03-09 18:44:19 +0100 | <EvanR> | no STArray does not |
| 2026-03-09 18:44:31 +0100 | <[exa]> | the above keeps references in Reader, where you only use the references for mutation, and don't modify the state |
| 2026-03-09 18:44:49 +0100 | <EvanR> | having an STArray in a State doesn't sound right at all |
| 2026-03-09 18:45:56 +0100 | <[exa]> | tccq: for comparison, did you work with mutable vectors? |
| 2026-03-09 18:46:28 +0100 | <tccq> | nope. I've done stuff w/ StateT and ReaderT (a while ago), but never really touched vectors or arrays in haskell |
| 2026-03-09 18:47:12 +0100 | <[exa]> | tccq: see https://hackage-content.haskell.org/package/vector-0.13.2.0/docs/Data-Vector-Mutable.html -- they are also parametrized by the `s` |
| 2026-03-09 18:47:47 +0100 | <[exa]> | tccq: but the 's' doesn't hold anything and actually cannot, because it's used internally for the state serialization (see the PrimMonad m constraints) |
| 2026-03-09 18:47:57 +0100 | <[exa]> | s/state/imperative computations/ |
| 2026-03-09 18:48:51 +0100 | <EvanR> | so you want to update a mutable array, let me first introduce you to some category theory |
| 2026-03-09 18:48:57 +0100 | <[exa]> | tccq: and with that single `s`, you can allocate and deallocate (and read&write) as many vectors/arrays as you like. The only thing they have in common is that their operations depend on each other (to assert order) via something that the `s` becomes. |
| 2026-03-09 18:49:48 +0100 | <tccq> | alright, think I've got it by the right end now, thank you |
| 2026-03-09 18:50:12 +0100 | <tccq> | the worst part is the the category theory isn't even that bad, it's the applications that are the hardest to parse ime |
| 2026-03-09 18:50:23 +0100 | <tccq> | but practice makes perfect I suppose |
| 2026-03-09 18:50:27 +0100 | <[exa]> | tccq: so then you have a bit of a choice of whether store stateful stuff in actual State, or have it "allocated aside" as a side effect, using e.g. the mutable vectors or STArrays, or e.g. TVar |
| 2026-03-09 18:50:44 +0100 | <EvanR> | I find vector is a good default when reaching for arrays |
| 2026-03-09 18:51:36 +0100 | <mauke> | stateful immutable arrays kind of suck because there are no partial updates. you can only rewrite the whole array |
| 2026-03-09 18:51:56 +0100 | <mauke> | so if you're dealing with array updates, State is not a good fit |
| 2026-03-09 18:52:18 +0100 | <[exa]> | ..is there a TVar that can be easily run in `ST s` ? |
| 2026-03-09 18:52:32 +0100 | <tccq> | I was only looking into STArrays because they seem relatively builtin |
| 2026-03-09 18:52:39 +0100 | <tccq> | though that line is never quite clear to me in haskell |
| 2026-03-09 18:53:05 +0100 | <[exa]> | tccq: builtin primitives might be tough :) |
| 2026-03-09 18:53:24 +0100 | <[exa]> | tbh I'd really recommend going with a mutable vector, it's a very friendly for first tries |
| 2026-03-09 18:53:42 +0100 | <[exa]> | *a very friendly choice |
| 2026-03-09 18:53:57 +0100 | <mauke> | [exa]: does that even make sense? how would you get a multi-threaded ST? |
| 2026-03-09 18:54:02 +0100 | <tccq> | I'll take a look through vector |
| 2026-03-09 18:54:32 +0100 | <tccq> | builtin meaning standard library, not necessarily VoidTM### or whatever goes on internally |
| 2026-03-09 18:54:55 +0100 | <tccq> | any the vague restriction of it would be cool to have it work with microhs too :) |
| 2026-03-09 18:54:58 +0100 | chele | (~chele@user/chele) (Remote host closed the connection) |
| 2026-03-09 18:55:01 +0100 | <tccq> | s/any/and |
| 2026-03-09 18:56:19 +0100 | <EvanR> | lol TVar. Here I was thinking it would be bad form to bring up STM in a discussion about the confusion between ST and State |
| 2026-03-09 18:58:34 +0100 | CiaoSen | (~Jura@2a02:8071:64e1:da0:5a47:caff:fe78:33db) CiaoSen |
| 2026-03-09 18:59:29 +0100 | <mauke> | yeah, love those names |
| 2026-03-09 19:00:26 +0100 | Square | (~Square@user/square) Square |
| 2026-03-09 19:00:27 +0100 | <mauke> | State: mutable state (emulated). STM: software transactional memory (for safe state in multi-threaded code). ST: state threads (not related to State or threads) |
| 2026-03-09 19:02:40 +0100 | Square2 | (~Square4@user/square) (Ping timeout: 245 seconds) |
| 2026-03-09 19:03:23 +0100 | wootehfoot | (~wootehfoo@user/wootehfoot) wootehfoot |
| 2026-03-09 19:04:54 +0100 | wickedjargon | (~user@S0106f89e28d5699a.vc.shawcable.net) wickedjargon |
| 2026-03-09 19:08:06 +0100 | <EvanR> | Data.Array is its own package now and not included in base? |
| 2026-03-09 19:08:17 +0100 | <EvanR> | or it always was |
| 2026-03-09 19:19:15 +0100 | euphores | (~SASL_euph@user/euphores) euphores |
| 2026-03-09 19:25:49 +0100 | <monochrom> | On my CV: "I know C/C++, J/Java/Javascript, ST/STM". >:) |
| 2026-03-09 19:26:43 +0100 | <monochrom> | yikes I should have "improved" that to "ST/STM/StateT/" too |
| 2026-03-09 19:42:26 +0100 | machinedgod | (~machinedg@d172-219-48-230.abhsia.telus.net) (Ping timeout: 248 seconds) |
| 2026-03-09 19:51:58 +0100 | DetourNetworkUK | (~DetourNet@user/DetourNetworkUK) (Read error: Connection reset by peer) |
| 2026-03-09 19:52:22 +0100 | DetourNetworkUK | (~DetourNet@user/DetourNetworkUK) DetourNetworkUK |
| 2026-03-09 19:52:40 +0100 | Everything | (~Everythin@172-232-54-192.ip.linodeusercontent.com) Everything |
| 2026-03-09 20:10:45 +0100 | <__monty__> | Forgot C-- as well. |
| 2026-03-09 20:11:22 +0100 | <monochrom> | I am not familiar enough with C--. |
| 2026-03-09 20:11:59 +0100 | <monochrom> | But I should be putting "C/C++/C#" there. :) |
| 2026-03-09 20:25:24 +0100 | Googulator | (~Googulato@2a01-036d-0106-0119-01e8-0aed-2fac-7c8a.pool6.digikabel.hu) (Quit: Client closed) |
| 2026-03-09 20:25:41 +0100 | Googulator | (~Googulato@2a01-036d-0106-0119-01e8-0aed-2fac-7c8a.pool6.digikabel.hu) |
| 2026-03-09 20:25:49 +0100 | <Rembane> | monochrom: Has your CV turned into a prefix tree? |
| 2026-03-09 20:25:58 +0100 | Everything | (~Everythin@172-232-54-192.ip.linodeusercontent.com) () |
| 2026-03-09 20:26:19 +0100 | arandombit | (~arandombi@2a02:2455:8656:7100:2149:c35e:cd23:4e9a) |
| 2026-03-09 20:26:19 +0100 | arandombit | (~arandombi@2a02:2455:8656:7100:2149:c35e:cd23:4e9a) (Changing host) |
| 2026-03-09 20:26:19 +0100 | arandombit | (~arandombi@user/arandombit) arandombit |
| 2026-03-09 20:26:29 +0100 | <monochrom> | haha |
| 2026-03-09 20:26:52 +0100 | karenw_ | (~karenw@user/karenw) karenw |
| 2026-03-09 20:26:57 +0100 | <monochrom> | Theorem: Every CV is a forest of prefix trees. >:) |
| 2026-03-09 20:27:18 +0100 | <Rembane> | I should start my CV with that theorem. :D |
| 2026-03-09 20:29:16 +0100 | igemnace | (~igemnace@user/igemnace) (Quit: ZNC 1.9.0+deb2build3 - https://znc.in) |
| 2026-03-09 20:30:10 +0100 | igemnace | (~igemnace@user/igemnace) igemnace |