Newest at the top
| 2025-11-14 20:27:49 +0100 | wootehfoot | (~wootehfoo@user/wootehfoot) wootehfoot |
| 2025-11-14 20:27:33 +0100 | <haskellbridge> | <loonycyborg> Handling out-of-memory conditions is notoriously hard problem. In this OOM state you can't rely on any functions that allocate more memory for any reason. |
| 2025-11-14 20:25:24 +0100 | haltingsolver | (~cmo@2604:3d09:207f:8000::d1dc) (Ping timeout: 260 seconds) |
| 2025-11-14 20:25:21 +0100 | <haskellbridge> | <loonycyborg> Unless runtime handles it transparently for the program. |
| 2025-11-14 20:24:51 +0100 | <haskellbridge> | <loonycyborg> This will have to be done in IO monad in any case. |
| 2025-11-14 20:21:55 +0100 | L29Ah | (~L29Ah@wikipedia/L29Ah) L29Ah |
| 2025-11-14 20:21:40 +0100 | humasect_ | (~humasect@dyn-192-249-132-90.nexicom.net) (Remote host closed the connection) |
| 2025-11-14 20:18:38 +0100 | Square3 | (~Square@user/square) Square |
| 2025-11-14 20:15:45 +0100 | jmcantrell | (~weechat@user/jmcantrell) jmcantrell |
| 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: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: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: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: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:06:11 +0100 | <haskellbridge> | <loonycyborg> Basically if same calculation gives different results when repeated then it's not pure. |
| 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: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:00:08 +0100 | L29Ah | (~L29Ah@wikipedia/L29Ah) () |
| 2025-11-14 19:56:16 +0100 | Lycurgus | (~juan@user/Lycurgus) (Quit: alsoknownas.renjuan.org ( juan@acm.org )) |
| 2025-11-14 19:55:04 +0100 | humasec__ | (~humasect@dyn-192-249-132-90.nexicom.net) (Ping timeout: 256 seconds) |
| 2025-11-14 19:54:35 +0100 | polykernel | (~polykerne@user/polykernel) polykernel |
| 2025-11-14 19:54:06 +0100 | eron | (~eron@187.56.155.181) (Quit: Client closed) |
| 2025-11-14 19:49:49 +0100 | humasect | (~humasect@dyn-192-249-132-90.nexicom.net) (Ping timeout: 260 seconds) |
| 2025-11-14 19:49:39 +0100 | humasec__ | (~humasect@dyn-192-249-132-90.nexicom.net) humasect |
| 2025-11-14 19:48:56 +0100 | humasect_ | (~humasect@dyn-192-249-132-90.nexicom.net) humasect |
| 2025-11-14 19:48:45 +0100 | Googulator53 | (~Googulato@team.broadbit.hu) (Ping timeout: 250 seconds) |
| 2025-11-14 19:46:41 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-11-14 19:39:16 +0100 | Lycurgus | (~juan@user/Lycurgus) Lycurgus |
| 2025-11-14 19:34:05 +0100 | comerijn | (~merijn@77.242.116.146) (Ping timeout: 256 seconds) |
| 2025-11-14 19:31:55 +0100 | <dolio> | handle (raise 1 + raise 2) with cases {r} -> r ; {raise n -> _} -> n |
| 2025-11-14 19:31:18 +0100 | <dolio> | The exact same problem happens if you use algebraic effects for them. |
| 2025-11-14 19:30:55 +0100 | <dolio> | My example is just using shift/reset to implement exceptions. |
| 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:28:49 +0100 | Googulator15 | (~Googulato@team.broadbit.hu) (Ping timeout: 250 seconds) |
| 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: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:26:07 +0100 | <jreicher> | Doesn't mean there aren't still other problems though |
| 2025-11-14 19:25:39 +0100 | Googulator53 | (~Googulato@team.broadbit.hu) |
| 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:23:21 +0100 | <dolio> | Zemyla: The problem is catching them. |
| 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:22:17 +0100 | humasect | (~humasect@dyn-192-249-132-90.nexicom.net) humasect |
| 2025-11-14 19:20:38 +0100 | myxos | (~myxos@2001:579:8380:f20:e1c:e3b9:dc1a:668f) myxokephale |
| 2025-11-14 19:16:02 +0100 | sord937 | (~sord937@gateway/tor-sasl/sord937) (Quit: sord937) |
| 2025-11-14 19:14:05 +0100 | Googulator78 | (~Googulato@team.broadbit.hu) (Ping timeout: 250 seconds) |
| 2025-11-14 19:10:47 +0100 | Googulator15 | (~Googulato@team.broadbit.hu) |
| 2025-11-14 19:10:32 +0100 | eron | (~eron@187.56.155.181) lidenbrock |
| 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:09:19 +0100 | Googulator43 | (~Googulato@team.broadbit.hu) (Ping timeout: 250 seconds) |
| 2025-11-14 19:08:26 +0100 | humasect | (~humasect@dyn-192-249-132-90.nexicom.net) (Remote host closed the connection) |