| 2025-11-14 00:03:17 +0100 | deptype | (~deptype@2406:b400:3a:73c2:bc7b:aa72:1b3f:1eab) (Remote host closed the connection) |
| 2025-11-14 00:03:37 +0100 | deptype | (~deptype@2406:b400:3a:73c2:d595:4e97:33b5:4927) |
| 2025-11-14 00:04:13 +0100 | peterbecich | (~Thunderbi@172.222.148.214) (Ping timeout: 264 seconds) |
| 2025-11-14 00:04:25 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-11-14 00:08:31 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 240 seconds) |
| 2025-11-14 00:09:49 +0100 | juri_ | (~juri@implicitcad.org) (Ping timeout: 246 seconds) |
| 2025-11-14 00:10:59 +0100 | mange | (~mange@user/mange) mange |
| 2025-11-14 00:12:43 +0100 | tromp | (~textual@2001:1c00:3487:1b00:7d:cf52:961a:9343) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2025-11-14 00:14:41 +0100 | sindu | (~sindu@46.67.16.220.tmi.telenormobil.no) (Ping timeout: 256 seconds) |
| 2025-11-14 00:14:58 +0100 | xff0x | (~xff0x@2405:6580:b080:900:7b8c:bddf:6c13:ed0c) (Ping timeout: 256 seconds) |
| 2025-11-14 00:16:18 +0100 | haltingsolver | (~cmo@2604:3d09:207f:8000::d1dc) (Remote host closed the connection) |
| 2025-11-14 00:16:40 +0100 | haltingsolver | (~cmo@2604:3d09:207f:8000::d1dc) |
| 2025-11-14 00:17:11 +0100 | sindu | (~sindu@2.148.52.19.tmi.telenormobil.no) |
| 2025-11-14 00:18:09 +0100 | humasect | (~humasect@dyn-192-249-132-90.nexicom.net) humasect |
| 2025-11-14 00:19:46 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-11-14 00:20:40 +0100 | <jreicher> | Does anyone have any practical experience, or know of a post that discusses it, for situations where shift/reset are adequate delimited continuation operators to use? The literature covers the situations where they're not enough, but I'm not sure there's much discussion about where they are? |
| 2025-11-14 00:22:10 +0100 | xff0x | (~xff0x@2405:6580:b080:900:7b8c:bddf:6c13:ed0c) |
| 2025-11-14 00:22:33 +0100 | ljdarj1 | (~Thunderbi@user/ljdarj) ljdarj |
| 2025-11-14 00:22:51 +0100 | deptype | (~deptype@2406:b400:3a:73c2:d595:4e97:33b5:4927) (Remote host closed the connection) |
| 2025-11-14 00:23:08 +0100 | deptype | (~deptype@2406:b400:3a:73c2:da7f:27b6:3903:8b8f) |
| 2025-11-14 00:24:19 +0100 | ljdarj | (~Thunderbi@user/ljdarj) (Ping timeout: 250 seconds) |
| 2025-11-14 00:24:19 +0100 | ljdarj1 | ljdarj |
| 2025-11-14 00:24:19 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 256 seconds) |
| 2025-11-14 00:29:45 +0100 | haskellbridge | (~hackager@96.28.224.214) (Remote host closed the connection) |
| 2025-11-14 00:30:24 +0100 | haskellbridge | (~hackager@96.28.224.214) hackager |
| 2025-11-14 00:30:24 +0100 | ChanServ | +v haskellbridge |
| 2025-11-14 00:34:00 +0100 | trickard_ | (~trickard@cpe-62-98-47-163.wireline.com.au) |
| 2025-11-14 00:34:49 +0100 | trickard | (~trickard@cpe-62-98-47-163.wireline.com.au) (Ping timeout: 264 seconds) |
| 2025-11-14 00:35:10 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-11-14 00:36:53 +0100 | juri_ | (~juri@implicitcad.org) juri_ |
| 2025-11-14 00:38:54 +0100 | bggd | (~bgg@2a01:e0a:819:1510:2f73:1c6d:ac1:52f7) (Quit: std::move) |
| 2025-11-14 00:38:54 +0100 | ljdarj | (~Thunderbi@user/ljdarj) (Read error: Connection reset by peer) |
| 2025-11-14 00:40:13 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 264 seconds) |
| 2025-11-14 00:42:25 +0100 | __monty__ | (~toonn@user/toonn) (Quit: leaving) |
| 2025-11-14 00:42:53 +0100 | deptype | (~deptype@2406:b400:3a:73c2:da7f:27b6:3903:8b8f) (Remote host closed the connection) |
| 2025-11-14 00:43:29 +0100 | deptype | (~deptype@2406:b400:3a:73c2:bb74:878e:87fe:72b5) |
| 2025-11-14 00:50:36 +0100 | catties | kitties |
| 2025-11-14 00:50:39 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-11-14 00:55:29 +0100 | sindu | (~sindu@2.148.52.19.tmi.telenormobil.no) (Ping timeout: 256 seconds) |
| 2025-11-14 00:57:46 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 256 seconds) |
| 2025-11-14 01:00:35 +0100 | annamalai | (~annamalai@157.33.224.236) (Ping timeout: 256 seconds) |
| 2025-11-14 01:03:25 +0100 | deptype | (~deptype@2406:b400:3a:73c2:bb74:878e:87fe:72b5) (Remote host closed the connection) |
| 2025-11-14 01:03:38 +0100 | deptype | (~deptype@2406:b400:3a:73c2:b60:8c10:d3ef:43c0) |
| 2025-11-14 01:05:54 +0100 | trickard_ | trickard |
| 2025-11-14 01:08:44 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-11-14 01:12:55 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 240 seconds) |
| 2025-11-14 01:16:05 +0100 | saurcron | (uid575716@user/saurcron) saurcron |
| 2025-11-14 01:23:28 +0100 | deptype | (~deptype@2406:b400:3a:73c2:b60:8c10:d3ef:43c0) (Remote host closed the connection) |
| 2025-11-14 01:23:41 +0100 | deptype | (~deptype@2406:b400:3a:73c2:6261:a427:7258:fcb4) |
| 2025-11-14 01:24:04 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-11-14 01:28:08 +0100 | bggd | (~bgg@2a01:e0a:819:1510:761:a174:4d6f:f8ab) |
| 2025-11-14 01:28:49 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 264 seconds) |
| 2025-11-14 01:32:12 +0100 | ryanbooker | (uid4340@id-4340.hampstead.irccloud.com) (Quit: Connection closed for inactivity) |
| 2025-11-14 01:37:13 +0100 | acarrico1 | (~acarrico@rb-sip-237.greenmountainaccess.net) |
| 2025-11-14 01:39:07 +0100 | mreh | (~matthew@host86-146-25-125.range86-146.btcentralplus.com) (Ping timeout: 256 seconds) |
| 2025-11-14 01:39:26 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-11-14 01:41:33 +0100 | acarrico1 | (~acarrico@rb-sip-237.greenmountainaccess.net) (Ping timeout: 244 seconds) |
| 2025-11-14 01:43:30 +0100 | deptype | (~deptype@2406:b400:3a:73c2:6261:a427:7258:fcb4) (Remote host closed the connection) |
| 2025-11-14 01:44:06 +0100 | deptype | (~deptype@2406:b400:3a:73c2:d1ef:54e1:33d0:7e62) |
| 2025-11-14 01:44:13 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 256 seconds) |
| 2025-11-14 01:46:26 +0100 | notzmv | (~umar@user/notzmv) notzmv |
| 2025-11-14 01:49:54 +0100 | xff0x | (~xff0x@2405:6580:b080:900:7b8c:bddf:6c13:ed0c) (Ping timeout: 256 seconds) |
| 2025-11-14 01:50:33 +0100 | acidjnk | (~acidjnk@p200300d6e71719864849111020082051.dip0.t-ipconnect.de) (Ping timeout: 250 seconds) |
| 2025-11-14 01:50:59 +0100 | kitties | Catty |
| 2025-11-14 01:52:09 +0100 | Tuplanolla | (~Tuplanoll@91-159-187-167.elisa-laajakaista.fi) (Ping timeout: 256 seconds) |
| 2025-11-14 01:53:04 +0100 | peterbecich | (~Thunderbi@172.222.148.214) peterbecich |
| 2025-11-14 01:54:49 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-11-14 01:55:57 +0100 | Googulator93 | (~Googulato@2a01-036d-0106-0180-68e2-7394-b68d-da19.pool6.digikabel.hu) |
| 2025-11-14 01:56:22 +0100 | humasect | (~humasect@dyn-192-249-132-90.nexicom.net) (Remote host closed the connection) |
| 2025-11-14 01:59:25 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 264 seconds) |
| 2025-11-14 02:03:32 +0100 | deptype | (~deptype@2406:b400:3a:73c2:d1ef:54e1:33d0:7e62) (Remote host closed the connection) |
| 2025-11-14 02:03:45 +0100 | deptype | (~deptype@2406:b400:3a:73c2:29fc:b984:2878:681b) |
| 2025-11-14 02:08:56 +0100 | jreicher | (~user@user/jreicher) (Ping timeout: 244 seconds) |
| 2025-11-14 02:09:35 +0100 | jreicher | (~user@user/jreicher) jreicher |
| 2025-11-14 02:10:13 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-11-14 02:14:31 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 240 seconds) |
| 2025-11-14 02:15:28 +0100 | trickard | (~trickard@cpe-62-98-47-163.wireline.com.au) (Ping timeout: 246 seconds) |
| 2025-11-14 02:15:57 +0100 | trickard_ | (~trickard@cpe-62-98-47-163.wireline.com.au) |
| 2025-11-14 02:16:13 +0100 | peterbecich | (~Thunderbi@172.222.148.214) (Ping timeout: 264 seconds) |
| 2025-11-14 02:23:04 +0100 | looking | (~looking@2600:4040:2678:9600:b1c4:ced3:242d:1252) |
| 2025-11-14 02:25:06 +0100 | looking | (~looking@2600:4040:2678:9600:b1c4:ced3:242d:1252) (Client Quit) |
| 2025-11-14 02:25:35 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-11-14 02:26:52 +0100 | humasect | (~humasect@dyn-192-249-132-90.nexicom.net) humasect |
| 2025-11-14 02:29:36 +0100 | _d0t | (~{-d0t-}@user/-d0t-/x-7915216) (Ping timeout: 252 seconds) |
| 2025-11-14 02:31:04 +0100 | deptype | (~deptype@2406:b400:3a:73c2:29fc:b984:2878:681b) (Remote host closed the connection) |
| 2025-11-14 02:31:17 +0100 | deptype | (~deptype@2406:b400:3a:73c2:d817:93dd:2198:fe22) |
| 2025-11-14 02:32:09 +0100 | humasect | (~humasect@dyn-192-249-132-90.nexicom.net) (Ping timeout: 250 seconds) |
| 2025-11-14 02:32:23 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 256 seconds) |
| 2025-11-14 02:35:26 +0100 | _d0t | (~{-d0t-}@user/-d0t-/x-7915216) {-d0t-} |
| 2025-11-14 02:41:15 +0100 | xff0x | (~xff0x@fsb6a9491c.tkyc517.ap.nuro.jp) |
| 2025-11-14 02:42:12 +0100 | humasect | (~humasect@dyn-192-249-132-90.nexicom.net) humasect |
| 2025-11-14 02:43:37 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-11-14 02:48:18 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
| 2025-11-14 02:53:24 +0100 | jumper149 | (~jumper149@base.felixspringer.xyz) (Quit: WeeChat 4.7.1) |
| 2025-11-14 02:56:32 +0100 | trickard_ | (~trickard@cpe-62-98-47-163.wireline.com.au) (Read error: Connection reset by peer) |
| 2025-11-14 02:56:47 +0100 | trickard_ | (~trickard@cpe-62-98-47-163.wireline.com.au) |
| 2025-11-14 02:57:36 +0100 | otto_s | (~user@p5b044407.dip0.t-ipconnect.de) (Ping timeout: 244 seconds) |
| 2025-11-14 02:59:00 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-11-14 03:03:19 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 240 seconds) |
| 2025-11-14 03:04:52 +0100 | haltingsolver | (~cmo@2604:3d09:207f:8000::d1dc) (Remote host closed the connection) |
| 2025-11-14 03:05:14 +0100 | haltingsolver | (~cmo@2604:3d09:207f:8000::d1dc) |
| 2025-11-14 03:07:49 +0100 | otto_s | (~user@p4ff27f5d.dip0.t-ipconnect.de) |
| 2025-11-14 03:14:23 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-11-14 03:14:47 +0100 | Nachtgespenst | (~user@user/siracusa) (Read error: Connection reset by peer) |
| 2025-11-14 03:15:02 +0100 | Nachtgespenst | (~user@user/siracusa) siracusa |
| 2025-11-14 03:15:28 +0100 | myxos | (~myxos@wsip-70-166-126-146.ph.ph.cox.net) (Quit: myxos) |
| 2025-11-14 03:16:27 +0100 | humasect_ | (~humasect@dyn-192-249-132-90.nexicom.net) humasect |
| 2025-11-14 03:18:51 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 256 seconds) |
| 2025-11-14 03:22:49 +0100 | humasect_ | (~humasect@dyn-192-249-132-90.nexicom.net) (Ping timeout: 264 seconds) |
| 2025-11-14 03:23:54 +0100 | humasect | (~humasect@dyn-192-249-132-90.nexicom.net) (Remote host closed the connection) |
| 2025-11-14 03:23:55 +0100 | <jackdk> | Maybe look up Alexis King's work on eff? |
| 2025-11-14 03:24:37 +0100 | <jreicher> | Yeah I did. That's one of the first introductions to it all I had. |
| 2025-11-14 03:24:55 +0100 | <jreicher> | But I couldn't find her spending much time on shift/reset. It was more about prompt/control and then prompt/control0 |
| 2025-11-14 03:29:46 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-11-14 03:34:07 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 250 seconds) |
| 2025-11-14 03:34:29 +0100 | ubert1 | (~Thunderbi@178.165.175.248.wireless.dyn.drei.com) ubert |
| 2025-11-14 03:37:33 +0100 | ubert | (~Thunderbi@178.165.182.105.wireless.dyn.drei.com) (Ping timeout: 256 seconds) |
| 2025-11-14 03:37:33 +0100 | ubert1 | ubert |
| 2025-11-14 03:41:28 +0100 | bggd | (~bgg@2a01:e0a:819:1510:761:a174:4d6f:f8ab) (Remote host closed the connection) |
| 2025-11-14 03:44:22 +0100 | <monochrom> | jreicher: My https://www.vex.net/~trebla/haskell/cont.xhtml#shift-reset (or the whole thing) |
| 2025-11-14 03:45:10 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-11-14 03:46:55 +0100 | myxos | (~myxos@2001:579:8380:f20:1406:c18d:98b3:27d1) myxokephale |
| 2025-11-14 03:50:01 +0100 | vanishingideal | (~vanishing@user/vanishingideal) (Ping timeout: 256 seconds) |
| 2025-11-14 03:50:02 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 256 seconds) |
| 2025-11-14 03:51:22 +0100 | humasect | (~humasect@dyn-192-249-132-90.nexicom.net) humasect |
| 2025-11-14 03:51:59 +0100 | deptype_ | (~deptype@124.123.128.236) |
| 2025-11-14 03:52:01 +0100 | vanishingideal | (~vanishing@user/vanishingideal) vanishingideal |
| 2025-11-14 03:53:23 +0100 | deptype__ | (~deptype@124.123.128.236) |
| 2025-11-14 03:55:08 +0100 | deptype | (~deptype@2406:b400:3a:73c2:d817:93dd:2198:fe22) (Ping timeout: 256 seconds) |
| 2025-11-14 03:55:13 +0100 | <jreicher> | OK, so the exercises you give there can be done in terms of shift/reset. In your experience is shift/reset "usually" enough for "most" situations? (I realise that's a vague question) |
| 2025-11-14 03:55:34 +0100 | <jreicher> | monochrom: ^ |
| 2025-11-14 03:55:35 +0100 | <monochrom> | Yes. |
| 2025-11-14 03:56:19 +0100 | <jreicher> | That's interesting. I couldn't tell for sure from the "theoretical" difference between static and dynamic, but it seemed to me it would be. |
| 2025-11-14 03:56:24 +0100 | humasect | (~humasect@dyn-192-249-132-90.nexicom.net) (Ping timeout: 244 seconds) |
| 2025-11-14 03:56:49 +0100 | deptype_ | (~deptype@124.123.128.236) (Ping timeout: 256 seconds) |
| 2025-11-14 03:59:03 +0100 | <monochrom> | I may be wrong in saying "lexically scoped". If you define "foo = shift ...", then it is foo's call sites that determines the corresponding reset. That is dynamic rather than static. |
| 2025-11-14 04:00:11 +0100 | <monochrom> | (In the same sense as: If you define "bar = x + 1", and if it is bar's call site that determines what x means, that is dynamic scoping.) |
| 2025-11-14 04:00:34 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-11-14 04:01:45 +0100 | <jreicher> | I think lexically scoped is correct. When shift captures the evaluation context it includes the reset, which is certainly a lexical scoping before anything else is done, and then the continuation is captured with that reset in exactly the same spot, which is effectively the same "spirit" as capture-avoiding substitution for beta-reduction, and so the lexical scoping is preserved. At least that's my take on it. |
| 2025-11-14 04:02:18 +0100 | <jreicher> | I meant to say "...and then the continuation is constructed..." |
| 2025-11-14 04:06:54 +0100 | annamalai | (~annamalai@157.32.194.69) annamalai |
| 2025-11-14 04:07:36 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 256 seconds) |
| 2025-11-14 04:11:25 +0100 | humasect | (~humasect@dyn-192-249-132-90.nexicom.net) humasect |
| 2025-11-14 04:16:49 +0100 | humasect | (~humasect@dyn-192-249-132-90.nexicom.net) (Ping timeout: 264 seconds) |
| 2025-11-14 04:18:36 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-11-14 04:23:01 +0100 | jmcantrell | (~weechat@user/jmcantrell) (Quit: WeeChat 4.7.1) |
| 2025-11-14 04:23:27 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 256 seconds) |
| 2025-11-14 04:24:16 +0100 | jmcantrell | (~weechat@user/jmcantrell) jmcantrell |
| 2025-11-14 04:27:10 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-11-14 04:27:16 +0100 | trickard_ | (~trickard@cpe-62-98-47-163.wireline.com.au) (Read error: Connection reset by peer) |
| 2025-11-14 04:27:30 +0100 | trickard_ | (~trickard@cpe-62-98-47-163.wireline.com.au) |
| 2025-11-14 04:28:00 +0100 | td__ | (~td@i53870917.versanet.de) (Ping timeout: 256 seconds) |
| 2025-11-14 04:29:49 +0100 | td_ | (~td@i53870933.versanet.de) |
| 2025-11-14 04:31:52 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 255 seconds) |
| 2025-11-14 04:42:33 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-11-14 04:47:25 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 264 seconds) |
| 2025-11-14 04:56:48 +0100 | <jreicher> | monochrom: Oh wait. Are you saying shift/reset might be dynamic in the sense that shift can be substituted into the scope of a reset? |
| 2025-11-14 04:57:56 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-11-14 05:02:07 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 244 seconds) |
| 2025-11-14 05:12:16 +0100 | <monochrom> | Yeah |
| 2025-11-14 05:13:18 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-11-14 05:14:24 +0100 | <jreicher> | Are you sure it can? There's a "shift v -> v" reduction rule, so if you had "\f shift f" and were reducing to a strong normal form, you'd get \f f, no? |
| 2025-11-14 05:15:12 +0100 | <jreicher> | Sorry that should asy reset instead of shift |
| 2025-11-14 05:15:53 +0100 | <jreicher> | I suspect if we dig into the semantics we'd find a barrier to the kind of substitution we're talking about |
| 2025-11-14 05:17:52 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 256 seconds) |
| 2025-11-14 05:28:41 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-11-14 05:33:09 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 256 seconds) |
| 2025-11-14 05:35:36 +0100 | ezzieyguywuf | (~Unknown@user/ezzieyguywuf) ezzieyguywuf |
| 2025-11-14 05:38:29 +0100 | Pixi | (~Pixi@user/pixi) (Ping timeout: 265 seconds) |
| 2025-11-14 05:44:04 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-11-14 05:51:01 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 264 seconds) |
| 2025-11-14 05:56:28 +0100 | Nachtgespenst | (~user@user/siracusa) (Quit: Bye!) |
| 2025-11-14 05:59:07 +0100 | humasect | (~humasect@dyn-192-249-132-90.nexicom.net) humasect |
| 2025-11-14 06:01:36 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-11-14 06:04:35 +0100 | humasect | (~humasect@dyn-192-249-132-90.nexicom.net) (Ping timeout: 265 seconds) |
| 2025-11-14 06:06:35 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 256 seconds) |
| 2025-11-14 06:08:37 +0100 | jmcantrell | (~weechat@user/jmcantrell) (Ping timeout: 255 seconds) |
| 2025-11-14 06:13:48 +0100 | amadaluzia | (~amadaluzi@user/amadaluzia) (Remote host closed the connection) |
| 2025-11-14 06:13:56 +0100 | amadaluzia | (~amadaluzi@user/amadaluzia) amadaluzia |
| 2025-11-14 06:17:08 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-11-14 06:21:35 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 245 seconds) |
| 2025-11-14 06:26:54 +0100 | fired | (~la@173-255-196-82.ip.linodeusercontent.com) (Quit: ZNC 1.9.1+deb1 - https://znc.in) |
| 2025-11-14 06:29:15 +0100 | machinedgod | (~machinedg@d75-159-126-101.abhsia.telus.net) (Ping timeout: 256 seconds) |
| 2025-11-14 06:29:22 +0100 | <jreicher> | If I've understood the semantics given by the extended CEK machine in the "static vs dynamic" paper, the shift is evaluated outside the context of a reset before the kind of substitution we're talking about, because it's a call-by-value machine. |
| 2025-11-14 06:32:37 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-11-14 06:35:59 +0100 | mange | (~mange@user/mange) (Remote host closed the connection) |
| 2025-11-14 06:37:49 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 264 seconds) |
| 2025-11-14 06:43:12 +0100 | humasect | (~humasect@dyn-192-249-132-90.nexicom.net) humasect |
| 2025-11-14 06:47:46 +0100 | humasect | (~humasect@dyn-192-249-132-90.nexicom.net) (Ping timeout: 255 seconds) |
| 2025-11-14 06:48:39 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-11-14 06:53:03 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 256 seconds) |
| 2025-11-14 06:54:57 +0100 | takuan | (~takuan@d8D86B9E9.access.telenet.be) |
| 2025-11-14 06:57:21 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) bitdex |
| 2025-11-14 06:58:48 +0100 | craunts795335385 | (~craunts@175.176.18.204) |
| 2025-11-14 07:01:42 +0100 | humasect | (~humasect@dyn-192-249-132-90.nexicom.net) humasect |
| 2025-11-14 07:02:24 +0100 | _d0t | (~{-d0t-}@user/-d0t-/x-7915216) (Ping timeout: 244 seconds) |
| 2025-11-14 07:04:03 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-11-14 07:04:09 +0100 | trickard__ | (~trickard@cpe-53-98-47-163.wireline.com.au) |
| 2025-11-14 07:05:19 +0100 | trickard_ | (~trickard@cpe-62-98-47-163.wireline.com.au) (Ping timeout: 255 seconds) |
| 2025-11-14 07:06:53 +0100 | humasect | (~humasect@dyn-192-249-132-90.nexicom.net) (Ping timeout: 250 seconds) |
| 2025-11-14 07:07:49 +0100 | _d0t | (~{-d0t-}@user/-d0t-/x-7915216) {-d0t-} |
| 2025-11-14 07:08:55 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 256 seconds) |
| 2025-11-14 07:10:38 +0100 | Sgeo | (~Sgeo@user/sgeo) (Ping timeout: 256 seconds) |
| 2025-11-14 07:13:07 +0100 | michalz | (~michalz@185.246.207.197) |
| 2025-11-14 07:19:12 +0100 | Sgeo | (~Sgeo@user/sgeo) Sgeo |
| 2025-11-14 07:19:26 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-11-14 07:20:09 +0100 | jreicher | (~user@user/jreicher) (Read error: Connection reset by peer) |
| 2025-11-14 07:21:08 +0100 | jreicher | (~user@user/jreicher) jreicher |
| 2025-11-14 07:23:43 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 240 seconds) |
| 2025-11-14 07:28:46 +0100 | haltingsolver | (~cmo@2604:3d09:207f:8000::d1dc) (Ping timeout: 256 seconds) |
| 2025-11-14 07:29:22 +0100 | Sgeo_ | (~Sgeo@user/sgeo) Sgeo |
| 2025-11-14 07:30:37 +0100 | Sgeo | (~Sgeo@user/sgeo) (Ping timeout: 264 seconds) |
| 2025-11-14 07:34:55 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-11-14 07:38:39 +0100 | Pixi | (~Pixi@user/pixi) Pixi |
| 2025-11-14 07:41:43 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 264 seconds) |
| 2025-11-14 07:42:46 +0100 | jreicher | (~user@user/jreicher) (Quit: brb) |
| 2025-11-14 07:49:05 +0100 | trickard__ | (~trickard@cpe-53-98-47-163.wireline.com.au) (Read error: Connection reset by peer) |
| 2025-11-14 07:49:18 +0100 | trickard_ | (~trickard@cpe-53-98-47-163.wireline.com.au) |
| 2025-11-14 07:49:35 +0100 | jreicher | (~user@user/jreicher) jreicher |
| 2025-11-14 07:52:58 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-11-14 07:57:25 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 246 seconds) |
| 2025-11-14 07:58:40 +0100 | poscat | (~poscat@user/poscat) (Remote host closed the connection) |
| 2025-11-14 07:59:44 +0100 | poscat | (~poscat@user/poscat) poscat |
| 2025-11-14 08:02:11 +0100 | Sgeo_ | (~Sgeo@user/sgeo) (Read error: Connection reset by peer) |
| 2025-11-14 08:02:36 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-11-14 08:07:17 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 256 seconds) |
| 2025-11-14 08:08:48 +0100 | poscat | (~poscat@user/poscat) (Remote host closed the connection) |
| 2025-11-14 08:09:28 +0100 | poscat | (~poscat@user/poscat) poscat |
| 2025-11-14 08:11:16 +0100 | craunts795335385 | (~craunts@175.176.18.204) (Quit: The Lounge - https://thelounge.chat) |
| 2025-11-14 08:18:05 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-11-14 08:22:24 +0100 | CiaoSen | (~Jura@2a02:8071:64e1:da0:5a47:caff:fe78:33db) CiaoSen |
| 2025-11-14 08:22:49 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 265 seconds) |
| 2025-11-14 08:26:26 +0100 | chromoblob | (~chromoblo@user/chromob1ot1c) (Remote host closed the connection) |
| 2025-11-14 08:26:42 +0100 | chromoblob | (~chromoblo@user/chromob1ot1c) chromoblob\0 |
| 2025-11-14 08:28:49 +0100 | annamalai | (~annamalai@157.32.194.69) (Ping timeout: 264 seconds) |
| 2025-11-14 08:29:27 +0100 | jreicher | (~user@user/jreicher) (Quit: brb) |
| 2025-11-14 08:30:12 +0100 | jreicher | (~user@user/jreicher) jreicher |
| 2025-11-14 08:33:01 +0100 | bliminse | (~bliminse@user/bliminse) (Quit: leaving) |
| 2025-11-14 08:33:12 +0100 | sprout_ | sprout |
| 2025-11-14 08:33:28 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-11-14 08:34:57 +0100 | peterbecich | (~Thunderbi@172.222.148.214) peterbecich |
| 2025-11-14 08:38:25 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 264 seconds) |
| 2025-11-14 08:47:16 +0100 | jreicher | (~user@user/jreicher) (Quit: brb) |
| 2025-11-14 08:47:58 +0100 | jreicher | (~user@user/jreicher) jreicher |
| 2025-11-14 08:48:52 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-11-14 08:48:54 +0100 | bliminse | (~bliminse@user/bliminse) bliminse |
| 2025-11-14 08:50:42 +0100 | lucabtz | (~lucabtz@user/lucabtz) lucabtz |
| 2025-11-14 08:53:07 +0100 | Googulator93 | (~Googulato@2a01-036d-0106-0180-68e2-7394-b68d-da19.pool6.digikabel.hu) (Ping timeout: 250 seconds) |
| 2025-11-14 08:53:25 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 246 seconds) |
| 2025-11-14 09:03:36 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-11-14 09:04:04 +0100 | sord937 | (~sord937@gateway/tor-sasl/sord937) sord937 |
| 2025-11-14 09:06:40 +0100 | vektor73 | (~vektor@2a02:b98:8a00:6b00:c51f:7bef:7501:f469) |
| 2025-11-14 09:08:29 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 256 seconds) |
| 2025-11-14 09:13:01 +0100 | humasect | (~humasect@dyn-192-249-132-90.nexicom.net) humasect |
| 2025-11-14 09:14:42 +0100 | annamalai | (~annamalai@157.32.197.187) annamalai |
| 2025-11-14 09:18:08 +0100 | humasect | (~humasect@dyn-192-249-132-90.nexicom.net) (Ping timeout: 256 seconds) |
| 2025-11-14 09:19:08 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-11-14 09:26:03 +0100 | vektor73 | (~vektor@2a02:b98:8a00:6b00:c51f:7bef:7501:f469) (Quit: Client closed) |
| 2025-11-14 09:26:04 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 256 seconds) |
| 2025-11-14 09:36:49 +0100 | peterbecich | (~Thunderbi@172.222.148.214) (Ping timeout: 256 seconds) |
| 2025-11-14 09:37:11 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-11-14 09:40:20 +0100 | tromp | (~textual@2001:1c00:3487:1b00:f8db:b16d:6074:eae9) |
| 2025-11-14 09:45:16 +0100 | emmanuelux | (~emmanuelu@user/emmanuelux) (Remote host closed the connection) |
| 2025-11-14 10:04:49 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 264 seconds) |
| 2025-11-14 10:06:19 +0100 | mreh | (~matthew@host86-146-25-125.range86-146.btcentralplus.com) |
| 2025-11-14 10:07:50 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-11-14 10:13:45 +0100 | jreicher | (~user@user/jreicher) (Quit: Last restart) |
| 2025-11-14 10:14:27 +0100 | jreicher | (~user@user/jreicher) jreicher |
| 2025-11-14 10:21:36 +0100 | humasect | (~humasect@dyn-192-249-132-90.nexicom.net) humasect |
| 2025-11-14 10:24:13 +0100 | Googulator93 | (~Googulato@team.broadbit.hu) |
| 2025-11-14 10:24:40 +0100 | trickard_ | (~trickard@cpe-53-98-47-163.wireline.com.au) (Read error: Connection reset by peer) |
| 2025-11-14 10:24:54 +0100 | trickard_ | (~trickard@cpe-53-98-47-163.wireline.com.au) |
| 2025-11-14 10:28:10 +0100 | tzh | (~tzh@c-76-115-131-146.hsd1.or.comcast.net) (Quit: zzz) |
| 2025-11-14 10:28:23 +0100 | j1n37 | (~j1n37@user/j1n37) (Ping timeout: 256 seconds) |
| 2025-11-14 10:30:18 +0100 | xff0x | (~xff0x@fsb6a9491c.tkyc517.ap.nuro.jp) (Ping timeout: 252 seconds) |
| 2025-11-14 10:30:56 +0100 | xff0x | (~xff0x@fsb6a9491c.tkyc517.ap.nuro.jp) |
| 2025-11-14 10:34:09 +0100 | trickard_ | (~trickard@cpe-53-98-47-163.wireline.com.au) (Read error: Connection reset by peer) |
| 2025-11-14 10:35:03 +0100 | trickard_ | (~trickard@cpe-53-98-47-163.wireline.com.au) |
| 2025-11-14 10:35:17 +0100 | Inline | (~inlinE@2001-4dd7-ae97-0-4674-ae6d-2607-c022.ipv6dyn.netcologne.de) (Remote host closed the connection) |
| 2025-11-14 10:37:30 +0100 | trickard_ | (~trickard@cpe-53-98-47-163.wireline.com.au) (Read error: Connection reset by peer) |
| 2025-11-14 10:38:48 +0100 | acidjnk | (~acidjnk@p200300d6e717192040ac95c287188d84.dip0.t-ipconnect.de) acidjnk |
| 2025-11-14 10:42:15 +0100 | j1n37 | (~j1n37@user/j1n37) j1n37 |
| 2025-11-14 10:45:28 +0100 | trickard_ | (~trickard@cpe-53-98-47-163.wireline.com.au) |
| 2025-11-14 10:49:18 +0100 | __monty__ | (~toonn@user/toonn) toonn |
| 2025-11-14 10:55:36 +0100 | xff0x | (~xff0x@fsb6a9491c.tkyc517.ap.nuro.jp) (Ping timeout: 256 seconds) |
| 2025-11-14 10:58:53 +0100 | Googulator93 | (~Googulato@team.broadbit.hu) (Quit: Client closed) |
| 2025-11-14 10:59:13 +0100 | Googulator93 | (~Googulato@team.broadbit.hu) |
| 2025-11-14 11:01:14 +0100 | Taneb | (~username@host-95-251-57-201.retail.telecomitalia.it) Taneb |
| 2025-11-14 11:10:34 +0100 | trickard_ | (~trickard@cpe-53-98-47-163.wireline.com.au) (Ping timeout: 255 seconds) |
| 2025-11-14 11:10:51 +0100 | trickard_ | (~trickard@cpe-53-98-47-163.wireline.com.au) |
| 2025-11-14 11:11:45 +0100 | ubert | (~Thunderbi@178.165.175.248.wireless.dyn.drei.com) (Quit: ubert) |
| 2025-11-14 11:12:01 +0100 | ubert | (~Thunderbi@178.165.175.248.wireless.dyn.drei.com) ubert |
| 2025-11-14 11:20:29 +0100 | myxokephale | (~myxos@2001:579:8380:f20:bec3:508e:c208:bae7) myxokephale |
| 2025-11-14 11:23:35 +0100 | myxos | (~myxos@2001:579:8380:f20:1406:c18d:98b3:27d1) (Ping timeout: 265 seconds) |
| 2025-11-14 11:33:00 +0100 | zeenk | (~zeenk@82.78.233.217) zeenk |
| 2025-11-14 11:38:22 +0100 | kuribas | (~user@ip-188-118-57-242.reverse.destiny.be) kuribas |
| 2025-11-14 11:42:51 +0100 | tromp | (~textual@2001:1c00:3487:1b00:f8db:b16d:6074:eae9) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2025-11-14 11:50:50 +0100 | tromp | (~textual@2001:1c00:3487:1b00:f8db:b16d:6074:eae9) |
| 2025-11-14 12:07:46 +0100 | rembo10 | (~rembo10@main.remulis.com) (Quit: ZNC 1.10.1 - https://znc.in) |
| 2025-11-14 12:09:00 +0100 | rembo10 | (~rembo10@main.remulis.com) rembo10 |
| 2025-11-14 12:12:00 +0100 | humasect | (~humasect@dyn-192-249-132-90.nexicom.net) (Remote host closed the connection) |
| 2025-11-14 12:32:49 +0100 | Googulator93 | (~Googulato@team.broadbit.hu) (Ping timeout: 250 seconds) |
| 2025-11-14 12:38:02 +0100 | trickard_ | trickard |
| 2025-11-14 12:41:59 +0100 | Vajb | (~Vajb@n60ck02t8pyq870qtsc-1.v6.elisa-mobile.fi) (Read error: Connection reset by peer) |
| 2025-11-14 12:43:08 +0100 | Vajb | (~Vajb@n5zpdagy4txm6luukqy-1.v6.elisa-mobile.fi) |
| 2025-11-14 12:45:31 +0100 | superbil | (~superbil@114-32-231-70.hinet-ip.hinet.net) (Ping timeout: 240 seconds) |
| 2025-11-14 12:47:23 +0100 | superbil | (~superbil@114-32-231-70.hinet-ip.hinet.net) superbil |
| 2025-11-14 12:52:01 +0100 | superbil | (~superbil@114-32-231-70.hinet-ip.hinet.net) (Ping timeout: 240 seconds) |
| 2025-11-14 12:52:24 +0100 | superbil | (~superbil@114-32-231-70.hinet-ip.hinet.net) superbil |
| 2025-11-14 12:54:34 +0100 | Nachtgespenst | (~user@user/siracusa) siracusa |
| 2025-11-14 12:54:55 +0100 | Vajb | (~Vajb@n5zpdagy4txm6luukqy-1.v6.elisa-mobile.fi) (Ping timeout: 264 seconds) |
| 2025-11-14 12:55:50 +0100 | Vajb | (~Vajb@n60ck02t8pyq870qtsc-1.v6.elisa-mobile.fi) |
| 2025-11-14 13:20:25 +0100 | trickard | (~trickard@cpe-53-98-47-163.wireline.com.au) (Read error: Connection reset by peer) |
| 2025-11-14 13:20:37 +0100 | trickard_ | (~trickard@cpe-53-98-47-163.wireline.com.au) |
| 2025-11-14 13:22:54 +0100 | Googulator93 | (~Googulato@team.broadbit.hu) |
| 2025-11-14 13:26:29 +0100 | wbrawner | (~wbrawner@129.146.105.153) (Remote host closed the connection) |
| 2025-11-14 13:26:46 +0100 | wbrawner | (~wbrawner@129.146.105.153) wbrawner |
| 2025-11-14 13:29:00 +0100 | acarrico1 | (~acarrico@pppoe-209-99-223-51.greenmountainaccess.net) |
| 2025-11-14 13:30:37 +0100 | trickard_ | (~trickard@cpe-53-98-47-163.wireline.com.au) (Ping timeout: 264 seconds) |
| 2025-11-14 13:31:27 +0100 | trickard_ | (~trickard@cpe-53-98-47-163.wireline.com.au) |
| 2025-11-14 13:31:29 +0100 | xff0x | (~xff0x@2405:6580:b080:900:6f96:f3d0:3ad2:3838) |
| 2025-11-14 13:36:13 +0100 | lucabtz | (~lucabtz@user/lucabtz) (Ping timeout: 246 seconds) |
| 2025-11-14 13:39:57 +0100 | lucabtz | (~lucabtz@user/lucabtz) lucabtz |
| 2025-11-14 13:56:10 +0100 | tromp | (~textual@2001:1c00:3487:1b00:f8db:b16d:6074:eae9) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2025-11-14 13:56:29 +0100 | fp | (~Thunderbi@wireless-86-50-140-45.open.aalto.fi) fp |
| 2025-11-14 14:02:26 +0100 | tromp | (~textual@2001:1c00:3487:1b00:f8db:b16d:6074:eae9) |
| 2025-11-14 14:26:05 +0100 | DetourNe- | (~DetourNet@user/DetourNetworkUK) DetourNetworkUK |
| 2025-11-14 14:26:31 +0100 | DetourNetworkUK | (~DetourNet@user/DetourNetworkUK) (Read error: Connection reset by peer) |
| 2025-11-14 14:28:19 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Quit: = "") |
| 2025-11-14 14:28:24 +0100 | DetourNe- | DetourNetworkUK |
| 2025-11-14 14:32:38 +0100 | Googulator93 | Googulator |
| 2025-11-14 14:33:43 +0100 | trickard_ | (~trickard@cpe-53-98-47-163.wireline.com.au) (Ping timeout: 240 seconds) |
| 2025-11-14 14:34:11 +0100 | trickard_ | (~trickard@cpe-53-98-47-163.wireline.com.au) |
| 2025-11-14 14:39:45 +0100 | trickard_ | trickard |
| 2025-11-14 14:42:30 +0100 | p3n | (~p3n@217.198.124.246) (Quit: ZNC 1.10.1 - https://znc.in) |
| 2025-11-14 14:50:59 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 250 seconds) |
| 2025-11-14 14:54:18 +0100 | p3n | (~p3n@217.198.124.246) p3n |
| 2025-11-14 14:54:20 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-11-14 15:04:21 +0100 | fp | (~Thunderbi@wireless-86-50-140-45.open.aalto.fi) (Ping timeout: 256 seconds) |
| 2025-11-14 15:06:53 +0100 | gorignak | (~gorignak@user/gorignak) gorignak |
| 2025-11-14 15:07:31 +0100 | annamalai | (~annamalai@157.32.197.187) (Remote host closed the connection) |
| 2025-11-14 15:09:47 +0100 | annamalai | (~annamalai@157.32.201.89) annamalai |
| 2025-11-14 15:11:04 +0100 | fp | (~Thunderbi@2001:708:150:10::7e06) fp |
| 2025-11-14 15:13:46 +0100 | fp1 | (~Thunderbi@wireless-86-50-140-45.open.aalto.fi) fp |
| 2025-11-14 15:13:50 +0100 | fp | (~Thunderbi@2001:708:150:10::7e06) (Client Quit) |
| 2025-11-14 15:13:51 +0100 | fp1 | fp |
| 2025-11-14 15:36:30 +0100 | <bwe> | Why does `Parsec Void Text` has no Eq? I am asking because I generate parsers and want to create unit tests, however realise now that Eq is missing... |
| 2025-11-14 15:37:15 +0100 | Sgeo | (~Sgeo@user/sgeo) Sgeo |
| 2025-11-14 15:37:43 +0100 | <merijn> | bwe: Because it's basically a function from text to a result? |
| 2025-11-14 15:38:03 +0100 | <merijn> | bwe: And identity on functions is notoriously hard problem, assuming you can even define what that means |
| 2025-11-14 15:38:13 +0100 | <merijn> | @quote strings.to.things |
| 2025-11-14 15:38:13 +0100 | <lambdabot> | No quotes match. Sorry. |
| 2025-11-14 15:38:17 +0100 | <merijn> | @quote string.to.things |
| 2025-11-14 15:38:18 +0100 | <lambdabot> | No quotes match. Maybe you made a typo? |
| 2025-11-14 15:38:19 +0100 | <merijn> | aww |
| 2025-11-14 15:38:24 +0100 | <merijn> | lambdabot, quit failing me |
| 2025-11-14 15:40:14 +0100 | <merijn> | @quote parser.for.things |
| 2025-11-14 15:40:14 +0100 | <lambdabot> | Dr._Seuss says: `type Parser a = String -> [(a,String)]' -- "A Parser for Things / is a function from Strings / to Lists of Pairs / of Things and Strings!" -- <https://willamette.edu/~fruehr/haskell/ |
| 2025-11-14 15:40:14 +0100 | <lambdabot> | seuss.html> |
| 2025-11-14 15:40:17 +0100 | <merijn> | There we go |
| 2025-11-14 15:45:15 +0100 | <merijn> | bwe: If you think about `Parsec Void Text e a` being approximately `Text -> Either e a` it's fairly self-explanatory why Eq does not exist. |
| 2025-11-14 15:45:39 +0100 | <merijn> | Well, I guess `Text -> Either e (a, Text)`, but you get the idea |
| 2025-11-14 15:46:03 +0100 | machinedgod | (~machinedg@d75-159-126-101.abhsia.telus.net) machinedgod |
| 2025-11-14 15:49:33 +0100 | trickard | (~trickard@cpe-53-98-47-163.wireline.com.au) (Read error: Connection reset by peer) |
| 2025-11-14 15:49:48 +0100 | trickard_ | (~trickard@cpe-53-98-47-163.wireline.com.au) |
| 2025-11-14 15:52:49 +0100 | pterobull1 | (~Thunderbi@S0106f8790a53b594.cg.shawcable.net) |
| 2025-11-14 15:54:19 +0100 | pterobull1 | (~Thunderbi@S0106f8790a53b594.cg.shawcable.net) (Client Quit) |
| 2025-11-14 16:02:43 +0100 | acarrico1 | (~acarrico@pppoe-209-99-223-51.greenmountainaccess.net) (Ping timeout: 256 seconds) |
| 2025-11-14 16:04:03 +0100 | CiaoSen | (~Jura@2a02:8071:64e1:da0:5a47:caff:fe78:33db) (Ping timeout: 260 seconds) |
| 2025-11-14 16:07:07 +0100 | pterobull | (~Thunderbi@S0106f8790a53b594.cg.shawcable.net) |
| 2025-11-14 16:07:46 +0100 | fp | (~Thunderbi@wireless-86-50-140-45.open.aalto.fi) (Ping timeout: 246 seconds) |
| 2025-11-14 16:10:56 +0100 | trickard_ | trickard |
| 2025-11-14 16:11:35 +0100 | pterobull | (~Thunderbi@S0106f8790a53b594.cg.shawcable.net) (Quit: pterobull) |
| 2025-11-14 16:13:50 +0100 | pterobul | (~Thunderbi@S0106f8790a53b594.cg.shawcable.net) |
| 2025-11-14 16:15:12 +0100 | comerijn | (~merijn@77.242.116.146) merijn |
| 2025-11-14 16:15:18 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Read error: Connection reset by peer) |
| 2025-11-14 16:20:41 +0100 | spew | (~spew@user/spew) spew |
| 2025-11-14 16:23:42 +0100 | Taneb | (~username@host-95-251-57-201.retail.telecomitalia.it) (Ping timeout: 256 seconds) |
| 2025-11-14 16:25:18 +0100 | spew | (~spew@user/spew) (Client Quit) |
| 2025-11-14 16:29:16 +0100 | YoungFrog | (~youngfrog@2a02:a03f:ca07:f900:9f50:13f1:779b:4aa6) (Quit: ZNC 1.7.x-git-3-96481995 - https://znc.in) |
| 2025-11-14 16:29:36 +0100 | YoungFrog | (~youngfrog@2a02:a03f:ca07:f900:5e58:dbf4:c0b:fbb3) youngfrog |
| 2025-11-14 16:30:09 +0100 | spew | (~spew@user/spew) spew |
| 2025-11-14 16:32:00 +0100 | weary-traveler | (~user@user/user363627) (Remote host closed the connection) |
| 2025-11-14 16:37:57 +0100 | pterobul | (~Thunderbi@S0106f8790a53b594.cg.shawcable.net) (Changing host) |
| 2025-11-14 16:37:57 +0100 | pterobul | (~Thunderbi@user/pterobul) pterobul |
| 2025-11-14 16:48:18 +0100 | ubert | (~Thunderbi@178.165.175.248.wireless.dyn.drei.com) (Ping timeout: 244 seconds) |
| 2025-11-14 16:48:38 +0100 | L29Ah | (~L29Ah@wikipedia/L29Ah) () |
| 2025-11-14 16:50:49 +0100 | megeve | (sid727922@id-727922.lymington.irccloud.com) megeve |
| 2025-11-14 16:52:54 +0100 | <dolio> | jreicher: In unison, we have a sort of algebraic effects that shift/reset is not enough to (easily) support. The difference is that you can have 'shallow' handlers that don't handle all the occurrences of an effect in the scope they're installed onto. That sort of corresponds to a single `reset` not guarding all the `shift` occurrences in its scope.... |
| 2025-11-14 16:53:31 +0100 | <dolio> | However, I think the vast majority of the time, people actually do define the 'deep' handler which does correspond to shift/reset. |
| 2025-11-14 16:53:45 +0100 | <lucabtz> | is there a way to have something similar to algebraic effects in haskell? |
| 2025-11-14 16:54:23 +0100 | <comerijn> | lucabtz: Only about a gazillion libraries |
| 2025-11-14 16:54:29 +0100 | <lucabtz> | cool |
| 2025-11-14 16:57:15 +0100 | <kuribas> | lol |
| 2025-11-14 16:57:54 +0100 | <[exa]> | the only thing more vast than the number of effect libraries in hackage is their accumulated time since last upload |
| 2025-11-14 16:58:09 +0100 | <[exa]> | lucabtz: you might like heftia |
| 2025-11-14 16:58:20 +0100 | <dolio> | mtl is like algebraic effects. |
| 2025-11-14 16:58:54 +0100 | <kuribas> | I still don't see the point of algebraic effects. |
| 2025-11-14 17:00:18 +0100 | <kuribas> | I could do "myFunction :: Monad m => (m UTCTime) -> ... -> m Result", I am now abstracted over currentTime. |
| 2025-11-14 17:01:00 +0100 | <kuribas> | if possible just "myFunction :: UTCTime -> ... -> Result" |
| 2025-11-14 17:01:01 +0100 | <geekosaur> | I see the point (better composition of effects ability to e.g. have two state effects and select by type) but I still am concerned that some effects aren't algebraic and pretending they are will just caause possibly subtle or corner-case breakage |
| 2025-11-14 17:01:14 +0100 | <comerijn> | What geekosaur said :p |
| 2025-11-14 17:01:59 +0100 | <geekosaur> | mtl is very careful to forbid combinations of effects that aren't safe |
| 2025-11-14 17:02:39 +0100 | <[exa]> | kuribas: imagine you have so much effect kinds that you think that an algebra over them would help you. |
| 2025-11-14 17:03:37 +0100 | <kuribas> | [exa]: I don't even see why I would want that... |
| 2025-11-14 17:03:59 +0100 | <comerijn> | Sometimes you gotta deal with things you don't want :p |
| 2025-11-14 17:04:02 +0100 | <kuribas> | I'd try to better separate pure from effectul code. |
| 2025-11-14 17:04:06 +0100 | <comerijn> | Because the alternative is worse |
| 2025-11-14 17:04:20 +0100 | <comerijn> | kuribas: I mean, that's nice and may work for you, but that doesn't mean it works for everything |
| 2025-11-14 17:04:42 +0100 | <kuribas> | comerijn: sure, maybe I haven't gotten a usecase where I would need it. |
| 2025-11-14 17:06:49 +0100 | <kuribas> | The only part where it sucks is in logging. |
| 2025-11-14 17:07:08 +0100 | <kuribas> | Because pure functions become IO due to logging. |
| 2025-11-14 17:09:41 +0100 | L29Ah | (~L29Ah@wikipedia/L29Ah) L29Ah |
| 2025-11-14 17:13:30 +0100 | <lucabtz> | [exa] i dont know a lot about algebraic effects but i dont see the point like kuribas |
| 2025-11-14 17:18:01 +0100 | Googulator | (~Googulato@team.broadbit.hu) (Quit: Client closed) |
| 2025-11-14 17:18:18 +0100 | Googulator | (~Googulato@team.broadbit.hu) |
| 2025-11-14 17:19:06 +0100 | <dolio> | I think it's more like there are many small 'points.' |
| 2025-11-14 17:20:48 +0100 | <dolio> | Like, Either is a bad way to implement exceptions, and assuming you use continuations to support your algebraic effects, the corresponding algebraic effect is automatically better, I think. |
| 2025-11-14 17:24:49 +0100 | DetourNetworkUK | (~DetourNet@user/DetourNetworkUK) (Read error: Connection reset by peer) |
| 2025-11-14 17:25:06 +0100 | DetourNe- | (DetourNetw@user/DetourNetworkUK) DetourNetworkUK |
| 2025-11-14 17:25:49 +0100 | spew | (~spew@user/spew) (Quit: WeeChat 4.6.3) |
| 2025-11-14 17:26:23 +0100 | <dolio> | And then having that baked in can influence the large scale design of things. You can do something better than Either in Haskell, but how many things are you going to have to wrap from returning Either? |
| 2025-11-14 17:26:43 +0100 | <dolio> | What if they could be designed the other way to begin with? |
| 2025-11-14 17:27:22 +0100 | DetourNe- | DetourNetworkUK |
| 2025-11-14 17:28:02 +0100 | Lord_of_Life_ | (~Lord@user/lord-of-life/x-2819915) Lord_of_Life |
| 2025-11-14 17:28:36 +0100 | <kuribas> | I just use IO exceptions |
| 2025-11-14 17:28:51 +0100 | <kuribas> | For exceptional things. Either for expected things (parser error, etc...). |
| 2025-11-14 17:29:08 +0100 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) (Ping timeout: 256 seconds) |
| 2025-11-14 17:29:19 +0100 | <comerijn> | I'd rather have checked IO exceptions, though |
| 2025-11-14 17:29:22 +0100 | Lord_of_Life_ | Lord_of_Life |
| 2025-11-14 17:29:50 +0100 | <dolio> | 'Just dump everything in IO' doesn't sound like a better answer. |
| 2025-11-14 17:30:23 +0100 | lucabtz | (~lucabtz@user/lucabtz) (Remote host closed the connection) |
| 2025-11-14 17:30:31 +0100 | <kuribas> | RIO is just fine for most of my applications. |
| 2025-11-14 17:30:41 +0100 | Googulator44 | (~Googulato@team.broadbit.hu) |
| 2025-11-14 17:30:46 +0100 | Inline | (~inlinE@2001-4dd7-ae97-0-4674-ae6d-2607-c022.ipv6dyn.netcologne.de) Inline |
| 2025-11-14 17:30:49 +0100 | <kuribas> | Still much better than a mess of global state in other languages. |
| 2025-11-14 17:30:52 +0100 | DetourNetworkUK | (DetourNetw@user/DetourNetworkUK) (Read error: Connection reset by peer) |
| 2025-11-14 17:31:11 +0100 | <dolio> | I mean, that is how you get well performing exceptions in GHC, but what if you could have catchable exceptions that performed that well, but were sound to use outside of IO? |
| 2025-11-14 17:31:40 +0100 | wootehfoot | (~wootehfoo@user/wootehfoot) (Read error: Connection reset by peer) |
| 2025-11-14 17:33:59 +0100 | Googulator | (~Googulato@team.broadbit.hu) (Ping timeout: 250 seconds) |
| 2025-11-14 17:34:14 +0100 | DetourNetworkUK | (~DetourNet@user/DetourNetworkUK) DetourNetworkUK |
| 2025-11-14 17:38:42 +0100 | <haskellbridge> | <loonycyborg> They're in IO only because the order they actually happen in at runtime is undefined. |
| 2025-11-14 17:38:59 +0100 | Anarchos | (~Anarchos@91-161-254-16.subs.proxad.net) Anarchos |
| 2025-11-14 17:39:26 +0100 | <haskellbridge> | <loonycyborg> I think it's possible to have pure exceptions too but then you'd have to get whole list of exceptions that happened, not random one of them |
| 2025-11-14 17:39:48 +0100 | <haskellbridge> | <loonycyborg> and then items in list can be in different order |
| 2025-11-14 17:40:08 +0100 | <haskellbridge> | <loonycyborg> so that should be unordered list which isn't a built-in feature in haskell |
| 2025-11-14 17:40:42 +0100 | bggd | (~bgg@2a01:e0a:819:1510:cb15:dfb4:31e5:1dfe) |
| 2025-11-14 17:43:21 +0100 | <haskellbridge> | <loonycyborg> In fact having a set(which is a list in no particular order) as a basic builtin type for a language like haskell would make sense I think :P |
| 2025-11-14 17:44:21 +0100 | Googulator44 | (~Googulato@team.broadbit.hu) (Quit: Client closed) |
| 2025-11-14 17:44:28 +0100 | <haskellbridge> | <loonycyborg> It's just implementing such containers is generally done via hashing and it just wasn't a widespread thing when haskell was originally designed |
| 2025-11-14 17:44:36 +0100 | Googulator44 | (~Googulato@team.broadbit.hu) |
| 2025-11-14 17:50:49 +0100 | img | (~img@user/img) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2025-11-14 17:50:50 +0100 | Googulator16 | (~Googulato@team.broadbit.hu) |
| 2025-11-14 17:52:07 +0100 | img | (~img@user/img) img |
| 2025-11-14 17:52:15 +0100 | <geekosaur> | well, in Haskell's case it had more to do with it being originally intended as a teaching and FP exploration language |
| 2025-11-14 17:52:33 +0100 | <geekosaur> | I mean, Perl, Python, and even awk already existed when Haskell was designed |
| 2025-11-14 17:52:40 +0100 | <geekosaur> | and Javascript |
| 2025-11-14 17:53:16 +0100 | <Leary> | loonycyborg: The issue with pure exceptions in Haskell is undefined evaluation order due to /laziness/. An effect system can easily provide deterministic, pure exception handling, so long as it imposes a strict sequencing of operations. |
| 2025-11-14 17:53:55 +0100 | Googulator44 | (~Googulato@team.broadbit.hu) (Ping timeout: 250 seconds) |
| 2025-11-14 17:53:55 +0100 | <comerijn> | geekosaur: What? |
| 2025-11-14 17:54:03 +0100 | <comerijn> | perl and awk, sure |
| 2025-11-14 17:54:09 +0100 | <comerijn> | Python's first public release was 1991 |
| 2025-11-14 17:54:42 +0100 | <comerijn> | So Haskell 1.0 predates it by a year |
| 2025-11-14 17:54:46 +0100 | acarrico1 | (~acarrico@pppoe-209-99-223-51.greenmountainaccess.net) |
| 2025-11-14 17:54:52 +0100 | <geekosaur> | python 1.0 and perl 32.0 came out the same week. I was comp.sources.misc moderator at the time and approved both |
| 2025-11-14 17:55:28 +0100 | <geekosaur> | which made it late 1980s |
| 2025-11-14 17:55:28 +0100 | <comerijn> | geekosaur: Wikipedia lists "Python implementation began in December 1989.[43] Van Rossum first released it in 1991 as Python 0.9.0" |
| 2025-11-14 17:57:44 +0100 | <comerijn> | The Haskell Committee started in 1987, predating python and the Haskell 1.0 was 1990. Not sure which compiler was first |
| 2025-11-14 17:58:00 +0100 | <comerijn> | iirc it was Lennart's compiler in Lazy ML? |
| 2025-11-14 17:59:29 +0100 | <dolio> | That's the usual story. |
| 2025-11-14 17:59:58 +0100 | <kuribas> | I wish I could write production code in idris. |
| 2025-11-14 18:00:32 +0100 | <comerijn> | I'm also confused by the qualifier "even" awk, as if awk is more modern than Perl and Python |
| 2025-11-14 18:00:49 +0100 | <comerijn> | Given that the first awk is from 1977 |
| 2025-11-14 18:02:04 +0100 | <haskellbridge> | <geekosaur> Mm right about ja |
| 2025-11-14 18:02:37 +0100 | <haskellbridge> | <Zemyla> Perl 32.0? I thought they were still working on Perl 6. |
| 2025-11-14 18:02:52 +0100 | <haskellbridge> | <geekosaur> Sorry I'm on my way to the store (sister's driving) |
| 2025-11-14 18:03:08 +0100 | Fijxu | (~Fijxu@user/fijxu) (Ping timeout: 256 seconds) |
| 2025-11-14 18:03:09 +0100 | tromp | (~textual@2001:1c00:3487:1b00:f8db:b16d:6074:eae9) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2025-11-14 18:03:23 +0100 | <haskellbridge> | <geekosaur> 3.0 not typing well |
| 2025-11-14 18:03:30 +0100 | <comerijn> | This should be obvious, given javascript was named after java, which is substantially newer than both Python and Haskell (since Java cribbed immutable strings from python, and python cribbed list comprehensions from haskell) |
| 2025-11-14 18:03:32 +0100 | <dolio> | Anyhow, back when I was working on ermine, I recall one thing we did was unsafe coerce exceptions into ST to try to borrow the more efficient handling that IO has. |
| 2025-11-14 18:03:41 +0100 | <haskellbridge> | <geekosaur> Bad time for me to be trying to do this |
| 2025-11-14 18:03:46 +0100 | <dolio> | We never really got to fruition with that implementation, though. |
| 2025-11-14 18:04:01 +0100 | <dolio> | But, like, what if you had that and it wasn't "you shouldn't be doing this." |
| 2025-11-14 18:05:43 +0100 | Googulator4 | (~Googulato@team.broadbit.hu) |
| 2025-11-14 18:05:47 +0100 | <dolio> | You probably do get that with the continuation-based algebraic effect things in Haskell. Because it's doing sort of the same thing for exceptions. |
| 2025-11-14 18:05:55 +0100 | <haskellbridge> | <geekosaur> But I'm pretty sure Perl and something claiming to be "Python" were late 80s |
| 2025-11-14 18:07:14 +0100 | <haskellbridge> | <loonycyborg> Leary: strict sequencing isn't necessarily a good thing. I'd prefer to embrace laziness(at least by default) and adapt to it. |
| 2025-11-14 18:08:07 +0100 | <haskellbridge> | <loonycyborg> And I see a way for that like this: gather all exceptions that happened into an unordered list and then pattern-match on it to find exception you want to handle. |
| 2025-11-14 18:09:05 +0100 | Googulator16 | (~Googulato@team.broadbit.hu) (Ping timeout: 250 seconds) |
| 2025-11-14 18:10:12 +0100 | polykernel | (~polykerne@user/polykernel) (Remote host closed the connection) |
| 2025-11-14 18:10:35 +0100 | polykernel | (~polykerne@user/polykernel) polykernel |
| 2025-11-14 18:15:42 +0100 | Googulator85 | (~Googulato@team.broadbit.hu) |
| 2025-11-14 18:16:16 +0100 | <jreicher> | dolio: is unison lazy? Since monochrom put me on to the question I've been trying to find examples of an implementation (or formal semantics) for delimited continuation operators on a lazy machine, as I think there does need to be something preventing a shift/control/etc "crossing" a reset/prompt/etc during substitution. |
| 2025-11-14 18:16:48 +0100 | <dolio> | No, it's not lazy. |
| 2025-11-14 18:17:38 +0100 | sindu | (~sindu@2.151.25.127.tmi.telenormobil.no) |
| 2025-11-14 18:18:04 +0100 | tromp | (~textual@2001:1c00:3487:1b00:f8db:b16d:6074:eae9) |
| 2025-11-14 18:18:16 +0100 | <haskellbridge> | <Zemyla> Okay, I'm trying to figure out how much performance I'd get if I made a mutable Seq in ST. |
| 2025-11-14 18:19:03 +0100 | Googulator4 | (~Googulato@team.broadbit.hu) (Ping timeout: 250 seconds) |
| 2025-11-14 18:19:30 +0100 | <haskellbridge> | <Zemyla> freeze would be safe and O(log n). |
| 2025-11-14 18:19:30 +0100 | <dolio> | Delimited continuations are effectful, so what happens if you allow them with laziness gets difficult to think about. And you'd have to commit to a particular lazy evaluation order, I think. |
| 2025-11-14 18:20:03 +0100 | <dolio> | Unlike Haskell where the exact order is somewhat unspecified (which can be an advantage). |
| 2025-11-14 18:20:24 +0100 | polykernel | (~polykerne@user/polykernel) (Remote host closed the connection) |
| 2025-11-14 18:20:44 +0100 | <comerijn> | dolio: It's not "somewhat unspecified" it's explicitly undefined |
| 2025-11-14 18:24:10 +0100 | <haskellbridge> | <Zemyla> You wouldn't have to de/reconstruct the digits. |
| 2025-11-14 18:24:14 +0100 | <jreicher> | dolio: No, I'm not sure they are inherently effectful. From what I can see you can still have church-rosser for delimited continuations |
| 2025-11-14 18:25:31 +0100 | acidjnk | (~acidjnk@p200300d6e717192040ac95c287188d84.dip0.t-ipconnect.de) (Ping timeout: 264 seconds) |
| 2025-11-14 18:28:46 +0100 | tromp | (~textual@2001:1c00:3487:1b00:f8db:b16d:6074:eae9) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2025-11-14 18:30:28 +0100 | tromp | (~textual@2001:1c00:3487:1b00:f8db:b16d:6074:eae9) |
| 2025-11-14 18:30:41 +0100 | Googulator89 | (~Googulato@team.broadbit.hu) |
| 2025-11-14 18:32:43 +0100 | <dolio> | reset ((shift _. 1) + (shift _. 2)) |
| 2025-11-14 18:32:49 +0100 | <dolio> | Is that 1 or 2? |
| 2025-11-14 18:33:47 +0100 | Googulator85 | (~Googulato@team.broadbit.hu) (Ping timeout: 250 seconds) |
| 2025-11-14 18:35:18 +0100 | <haskellbridge> | <Zemyla> Also, I'm wondering if you'd get any kind of significant savings by having sized :: Sized a => a -> Int# instead of a -> Int. |
| 2025-11-14 18:36:05 +0100 | <Leary> | loonycyborg: When an exception is raised, it prevents further execution. As such, there will only ever be one exception to handle. The issue is that it's undefined /which/ exception that will be. |
| 2025-11-14 18:36:30 +0100 | humasect | (~humasect@dyn-192-249-132-90.nexicom.net) humasect |
| 2025-11-14 18:38:04 +0100 | <haskellbridge> | <loonycyborg> It's not necessarily true for particular runtime. They still can evaluate other parts of complex value even if got exception from one of the parts |
| 2025-11-14 18:38:09 +0100 | <jreicher> | dolio: I don't know, but I can see in the literature references to delimited continuations with church-rosser. I'm trying to figure out how they work now. They build on lambda-mu, but even lambda-mu doesn't have church-rosser I think. |
| 2025-11-14 18:39:24 +0100 | <haskellbridge> | <loonycyborg> You can implement exceptions as any type implicitly becoming Either |
| 2025-11-14 18:40:06 +0100 | tromp | (~textual@2001:1c00:3487:1b00:f8db:b16d:6074:eae9) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2025-11-14 18:41:43 +0100 | <haskellbridge> | <loonycyborg> That's the whole deal with "pure" exceptions, all parts of evaluation chain exist no matter what. But runtime can evaluate them in any order |
| 2025-11-14 18:42:03 +0100 | <dolio> | The only ways I know of off hand to fix this are 1) enforce linear use of continuations and 2) fix an evaluation order so that Church-Rosser is a vacuous property. |
| 2025-11-14 18:42:13 +0100 | <haskellbridge> | <loonycyborg> if runtime picks just one exception among them then whole calculation isn't pure anymore |
| 2025-11-14 18:42:34 +0100 | <haskellbridge> | <loonycyborg> but if it takes all in no particular order it still can be pure |
| 2025-11-14 18:42:41 +0100 | <dolio> | But maybe there are others. |
| 2025-11-14 18:43:08 +0100 | tromp | (~textual@2001:1c00:3487:1b00:f8db:b16d:6074:eae9) |
| 2025-11-14 18:43:46 +0100 | <haskellbridge> | <loonycyborg> Like exceptions will be as deterministic as non-exceptional values |
| 2025-11-14 18:45:21 +0100 | haltingsolver | (~cmo@2604:3d09:207f:8000::d1dc) |
| 2025-11-14 18:45:35 +0100 | acarrico1 | (~acarrico@pppoe-209-99-223-51.greenmountainaccess.net) (Ping timeout: 244 seconds) |
| 2025-11-14 18:45:54 +0100 | kuribas | (~user@ip-188-118-57-242.reverse.destiny.be) (Remote host closed the connection) |
| 2025-11-14 18:48:26 +0100 | humasect | (~humasect@dyn-192-249-132-90.nexicom.net) (Remote host closed the connection) |
| 2025-11-14 18:52:50 +0100 | humasect | (~humasect@dyn-192-249-132-90.nexicom.net) humasect |
| 2025-11-14 18:55:47 +0100 | Googulator43 | (~Googulato@team.broadbit.hu) |
| 2025-11-14 18:57:24 +0100 | tzh | (~tzh@c-76-115-131-146.hsd1.or.comcast.net) tzh |
| 2025-11-14 18:58:55 +0100 | Googulator89 | (~Googulato@team.broadbit.hu) (Ping timeout: 250 seconds) |
| 2025-11-14 19:01:03 +0100 | <haskellbridge> | <Zemyla> In practice, how much does it matter that exceptions are non-deterministic? If they show up in a pure computation, then that computation was hosed anyway. If they show up in non-parallel IO, then it's deterministic. And if they show up in parallel IO, then you either handled them incorrectly or it was hosed. |
| 2025-11-14 19:02:50 +0100 | <davean> | wait who said it was deterministic if it showed up in non-parallel IO? |
| 2025-11-14 19:03:01 +0100 | <davean> | and what do you mean that the computation for pure computation was hosed anyway? |
| 2025-11-14 19:03:11 +0100 | <davean> | You could just rerun it and not get the exception. |
| 2025-11-14 19:03:29 +0100 | <haskellbridge> | <Zemyla> If you have quot 1 0 + quot minBound (-1), does it really matter whether it threw a division by zero or an overflow? |
| 2025-11-14 19:04:05 +0100 | <davean> | Yes, that says something about what type you're in. More importantly thoguh it matters a LOT if what it threw was OutOfMemory |
| 2025-11-14 19:04:23 +0100 | <davean> | or AsyncException |
| 2025-11-14 19:04:26 +0100 | <davean> | or ... |
| 2025-11-14 19:06:03 +0100 | Googulator78 | (~Googulato@team.broadbit.hu) |
| 2025-11-14 19:08:26 +0100 | humasect | (~humasect@dyn-192-249-132-90.nexicom.net) (Remote host closed the connection) |
| 2025-11-14 19:09:19 +0100 | Googulator43 | (~Googulato@team.broadbit.hu) (Ping timeout: 250 seconds) |
| 2025-11-14 19:09:34 +0100 | tromp | (~textual@2001:1c00:3487:1b00:f8db:b16d:6074:eae9) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2025-11-14 19:10:32 +0100 | eron | (~eron@187.56.155.181) lidenbrock |
| 2025-11-14 19:10:47 +0100 | Googulator15 | (~Googulato@team.broadbit.hu) |
| 2025-11-14 19:14:05 +0100 | Googulator78 | (~Googulato@team.broadbit.hu) (Ping timeout: 250 seconds) |
| 2025-11-14 19:16:02 +0100 | sord937 | (~sord937@gateway/tor-sasl/sord937) (Quit: sord937) |
| 2025-11-14 19:20:38 +0100 | myxos | (~myxos@2001:579:8380:f20:e1c:e3b9:dc1a:668f) myxokephale |
| 2025-11-14 19:22:17 +0100 | humasect | (~humasect@dyn-192-249-132-90.nexicom.net) humasect |
| 2025-11-14 19:23:04 +0100 | myxokephale | (~myxos@2001:579:8380:f20:bec3:508e:c208:bae7) (Ping timeout: 246 seconds) |
| 2025-11-14 19:23:21 +0100 | <dolio> | Zemyla: The problem is catching them. |
| 2025-11-14 19:25:20 +0100 | <jreicher> | dolio: I think the problem in your example is that the "handler" is given in the shift operator. The problem is solved if it's given in the reset operator. Then there can be only one handler per capture scope. |
| 2025-11-14 19:25:39 +0100 | Googulator53 | (~Googulato@team.broadbit.hu) |
| 2025-11-14 19:26:07 +0100 | <jreicher> | Doesn't mean there aren't still other problems though |
| 2025-11-14 19:26:34 +0100 | <dolio> | Algebraic effects have handlers that let you handle the effects, but then you need the effects to have a deterministic order to get deterministic handler results. |
| 2025-11-14 19:27:55 +0100 | <jreicher> | That's what I would expect. I'm still thinking it through, and I'm still trying to figure out how the different calculi and operator designs relate. |
| 2025-11-14 19:28:49 +0100 | Googulator15 | (~Googulato@team.broadbit.hu) (Ping timeout: 250 seconds) |
| 2025-11-14 19:28:55 +0100 | <jreicher> | Have to head off for a bit. Thanks heaps for your thoughts; helps a lot. |
| 2025-11-14 19:30:55 +0100 | <dolio> | My example is just using shift/reset to implement exceptions. |
| 2025-11-14 19:31:18 +0100 | <dolio> | The exact same problem happens if you use algebraic effects for them. |
| 2025-11-14 19:31:55 +0100 | <dolio> | handle (raise 1 + raise 2) with cases {r} -> r ; {raise n -> _} -> n |
| 2025-11-14 19:34:05 +0100 | comerijn | (~merijn@77.242.116.146) (Ping timeout: 256 seconds) |
| 2025-11-14 19:39:16 +0100 | Lycurgus | (~juan@user/Lycurgus) Lycurgus |
| 2025-11-14 19:46:41 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-11-14 19:48:45 +0100 | Googulator53 | (~Googulato@team.broadbit.hu) (Ping timeout: 250 seconds) |
| 2025-11-14 19:48:56 +0100 | humasect_ | (~humasect@dyn-192-249-132-90.nexicom.net) humasect |
| 2025-11-14 19:49:39 +0100 | humasec__ | (~humasect@dyn-192-249-132-90.nexicom.net) humasect |
| 2025-11-14 19:49:49 +0100 | humasect | (~humasect@dyn-192-249-132-90.nexicom.net) (Ping timeout: 260 seconds) |
| 2025-11-14 19:54:06 +0100 | eron | (~eron@187.56.155.181) (Quit: Client closed) |
| 2025-11-14 19:54:35 +0100 | polykernel | (~polykerne@user/polykernel) polykernel |
| 2025-11-14 19:55:04 +0100 | humasec__ | (~humasect@dyn-192-249-132-90.nexicom.net) (Ping timeout: 256 seconds) |
| 2025-11-14 19:56:16 +0100 | Lycurgus | (~juan@user/Lycurgus) (Quit: alsoknownas.renjuan.org ( juan@acm.org )) |
| 2025-11-14 20:00:08 +0100 | L29Ah | (~L29Ah@wikipedia/L29Ah) () |
| 2025-11-14 20:04:09 +0100 | <haskellbridge> | <loonycyborg> davean: I don't think you'd be ever able to handle out of memory error as a pure exception. Because if results are determined by something other than values themselves(like where are they stored) then things are most definitely not pure anymore. |
| 2025-11-14 20:04:47 +0100 | <haskellbridge> | <loonycyborg> While something like integer overflow can be handled as a pure exception. Because same calculation with same values will always cause overflow |
| 2025-11-14 20:06:11 +0100 | <haskellbridge> | <loonycyborg> Basically if same calculation gives different results when repeated then it's not pure. |
| 2025-11-14 20:09:34 +0100 | <haskellbridge> | <loonycyborg> If you have a tuple with two values that both cause some overflow exception or other deterministic condition like that then you still can get a deterministic list of those exceptions and entire thing will be pure because it depends only on input values |
| 2025-11-14 20:09:42 +0100 | <davean> | Leary: you can't handle them in the pure code, but you CAN handle them in the IO and then retry |
| 2025-11-14 20:10:15 +0100 | <haskellbridge> | <loonycyborg> while memory overflow handling depends on other parameters that we don't track so it cannot ever be pure |
| 2025-11-14 20:12:43 +0100 | <haskellbridge> | <loonycyborg> I guess we could track memory as extra value(s) and make things pure that way but that would be just excessively complex :P |
| 2025-11-14 20:14:16 +0100 | <davean> | I mean you can see it failed, free memory, and then try again |
| 2025-11-14 20:15:45 +0100 | jmcantrell | (~weechat@user/jmcantrell) jmcantrell |