Newest at the top
| 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) |
| 2025-11-14 19:06:03 +0100 | Googulator78 | (~Googulato@team.broadbit.hu) |
| 2025-11-14 19:04:26 +0100 | <davean> | or ... |
| 2025-11-14 19:04:23 +0100 | <davean> | or AsyncException |
| 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: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:03:11 +0100 | <davean> | You could just rerun it and not get the exception. |
| 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:02:50 +0100 | <davean> | wait who said it was deterministic if it showed up in non-parallel IO? |
| 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 18:58:55 +0100 | Googulator89 | (~Googulato@team.broadbit.hu) (Ping timeout: 250 seconds) |
| 2025-11-14 18:57:24 +0100 | tzh | (~tzh@c-76-115-131-146.hsd1.or.comcast.net) tzh |