Newest at the top
| 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. |
| 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:33:47 +0100 | Googulator85 | (~Googulato@team.broadbit.hu) (Ping timeout: 250 seconds) |
| 2025-11-14 18:32:49 +0100 | <dolio> | Is that 1 or 2? |
| 2025-11-14 18:32:43 +0100 | <dolio> | reset ((shift _. 1) + (shift _. 2)) |
| 2025-11-14 18:30:41 +0100 | Googulator89 | (~Googulato@team.broadbit.hu) |
| 2025-11-14 18:30:28 +0100 | tromp | (~textual@2001:1c00:3487:1b00:f8db:b16d:6074:eae9) |
| 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:25:31 +0100 | acidjnk | (~acidjnk@p200300d6e717192040ac95c287188d84.dip0.t-ipconnect.de) (Ping timeout: 264 seconds) |
| 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:24:10 +0100 | <haskellbridge> | <Zemyla> You wouldn't have to de/reconstruct the digits. |
| 2025-11-14 18:20:44 +0100 | <comerijn> | dolio: It's not "somewhat unspecified" it's explicitly undefined |
| 2025-11-14 18:20:24 +0100 | polykernel | (~polykerne@user/polykernel) (Remote host closed the connection) |
| 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: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:19:30 +0100 | <haskellbridge> | <Zemyla> freeze would be safe and O(log n). |
| 2025-11-14 18:19:03 +0100 | Googulator4 | (~Googulato@team.broadbit.hu) (Ping timeout: 250 seconds) |
| 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:18:04 +0100 | tromp | (~textual@2001:1c00:3487:1b00:f8db:b16d:6074:eae9) |
| 2025-11-14 18:17:38 +0100 | sindu | (~sindu@2.151.25.127.tmi.telenormobil.no) |
| 2025-11-14 18:16:48 +0100 | <dolio> | No, it's not lazy. |
| 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. |