Newest at the top
| 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 |
| 2025-11-14 18:55:47 +0100 | Googulator43 | (~Googulato@team.broadbit.hu) |
| 2025-11-14 18:52:50 +0100 | humasect | (~humasect@dyn-192-249-132-90.nexicom.net) humasect |
| 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:45:54 +0100 | kuribas | (~user@ip-188-118-57-242.reverse.destiny.be) (Remote host closed the connection) |
| 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:21 +0100 | haltingsolver | (~cmo@2604:3d09:207f:8000::d1dc) |
| 2025-11-14 18:43:46 +0100 | <haskellbridge> | <loonycyborg> Like exceptions will be as deterministic as non-exceptional values |
| 2025-11-14 18:43:08 +0100 | tromp | (~textual@2001:1c00:3487:1b00:f8db:b16d:6074:eae9) |
| 2025-11-14 18:42:41 +0100 | <dolio> | But maybe there are others. |
| 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:13 +0100 | <haskellbridge> | <loonycyborg> if runtime picks just one exception among them then whole calculation isn't pure anymore |
| 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: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: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:39:24 +0100 | <haskellbridge> | <loonycyborg> You can implement exceptions as any type implicitly becoming Either |
| 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: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:36:30 +0100 | humasect | (~humasect@dyn-192-249-132-90.nexicom.net) humasect |
| 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. |