Newest at the top
| 2025-11-14 20:44:07 +0100 | jmcantrell | (~weechat@user/jmcantrell) (Ping timeout: 264 seconds) |
| 2025-11-14 20:40:31 +0100 | mreh | (~matthew@host86-146-25-125.range86-146.btcentralplus.com) (Quit: Lost terminal) |
| 2025-11-14 20:39:43 +0100 | eron | (~eron@187.56.155.181) lidenbrock |
| 2025-11-14 20:39:10 +0100 | <haskellbridge> | <loonycyborg> But things like integer overflow and divide by zero are deterministic and can be considered separate form of resulting value. |
| 2025-11-14 20:38:21 +0100 | <haskellbridge> | <loonycyborg> And trying to handle them purely would violate all sort of things like referential transparency :P |
| 2025-11-14 20:36:24 +0100 | <haskellbridge> | <loonycyborg> Some of them most definitely aren't |
| 2025-11-14 20:34:03 +0100 | <davean> | Lots of quality software handles these signals. Thats not the point though, the point is that exceptions in pure code *are not deterministic* |
| 2025-11-14 20:32:46 +0100 | <davean> | Actually there is a clear signal if you don't have overcommit, you get an alloc fail |
| 2025-11-14 20:32:18 +0100 | <haskellbridge> | <loonycyborg> In practice any OOM handlers don't get much workout either. If PC runs out of memory OS either moves things to swapfile or kills some processes with signal that can't be trapped |
| 2025-11-14 20:31:30 +0100 | notzmv | (~umar@user/notzmv) (Ping timeout: 244 seconds) |
| 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. |