Newest at the top
| 2024-11-07 03:39:26 +0100 | Unicorn_Princess | (~Unicorn_P@user/Unicorn-Princess/x-3540542) (Remote host closed the connection) |
| 2024-11-07 03:37:20 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-11-07 03:35:29 +0100 | troojg | (~troojg@user/troojg) (Ping timeout: 248 seconds) |
| 2024-11-07 03:32:31 +0100 | ryanbooker | (uid4340@id-4340.hampstead.irccloud.com) ryanbooker |
| 2024-11-07 03:26:59 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 260 seconds) |
| 2024-11-07 03:23:46 +0100 | Unicorn_Princess | (~Unicorn_P@user/Unicorn-Princess/x-3540542) Unicorn_Princess |
| 2024-11-07 03:21:59 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-11-07 03:18:08 +0100 | TonyStone | (~TonyStone@user/TonyStone) TonyStone |
| 2024-11-07 03:14:40 +0100 | spew | (~spew@201.141.99.170) (Quit: spew) |
| 2024-11-07 03:12:01 +0100 | machinedgod | (~machinedg@d108-173-18-100.abhsia.telus.net) (Ping timeout: 248 seconds) |
| 2024-11-07 03:10:48 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 245 seconds) |
| 2024-11-07 03:06:36 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-11-07 03:05:27 +0100 | gmg | (~user@user/gehmehgeh) gehmehgeh |
| 2024-11-07 03:05:11 +0100 | chiselfuse | (~chiselfus@user/chiselfuse) chiselfuse |
| 2024-11-07 03:03:50 +0100 | califax_ | califax |
| 2024-11-07 03:03:36 +0100 | chiselfuse | (~chiselfus@user/chiselfuse) (Ping timeout: 260 seconds) |
| 2024-11-07 03:03:36 +0100 | califax | (~califax@user/califx) (Ping timeout: 260 seconds) |
| 2024-11-07 03:03:14 +0100 | TonyStone | (~TonyStone@user/TonyStone) (Ping timeout: 260 seconds) |
| 2024-11-07 03:03:01 +0100 | gmg | (~user@user/gehmehgeh) (Ping timeout: 260 seconds) |
| 2024-11-07 03:02:30 +0100 | califax_ | (~califax@user/califx) califx |
| 2024-11-07 03:02:03 +0100 | LainExperiments | (~LainExper@user/LainExperiments) (Ping timeout: 256 seconds) |
| 2024-11-07 02:55:39 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 260 seconds) |
| 2024-11-07 02:54:18 +0100 | <Leary> | , the interface would just be more strongly typed. |
| 2024-11-07 02:54:18 +0100 | <Leary> | We could (and imo should) have unchecked panics (anywhere) and statically checked exceptions (IO/ST only) with `IO/ST :: [Exception] -> Type -> Type` uniting exception sets in `<*>`/`>>=` while `try`/`catch` delete one and `main :: IO [] (); runST :: (forall s. ST [] a) -> a`. Interruptible operations would necessarily include async exceptions in the type-level list of exceptions they might throw. The actual implementation would be essentially unchanged |
| 2024-11-07 02:51:12 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-11-07 02:49:58 +0100 | euleritian | (~euleritia@77.22.252.56) |
| 2024-11-07 02:49:39 +0100 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Remote host closed the connection) |
| 2024-11-07 02:46:40 +0100 | <dolio> | For scenarios where exceptions are actually exceptional, you want an alternate implementation, like continuations for algebraic effects, so that you just install a handler once and you only jump out to it when there actually is an exception. It's technically the same 'type,' but one implementation is far superior for how it will likely be used. |
| 2024-11-07 02:42:02 +0100 | <dolio> | Which is possible, but then you probably have a lot of lifting and lowering to do. And also, the transformer will probably have abysmal performance characteristics, because it will repeatedly be building and inspecting Either values for the expected common case of not having an exception. |
| 2024-11-07 02:40:29 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 260 seconds) |
| 2024-11-07 02:39:52 +0100 | <dolio> | E.G. if you don't want to locally handle an explicit `Either` result, then you need to use a monad transformer or something. |
| 2024-11-07 02:38:52 +0100 | <dolio> | If you mean asynchronous exceptions, then you are unnecessarily conflating that with other aspects of the exception API. |
| 2024-11-07 02:35:50 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-11-07 02:29:46 +0100 | LainExperiments | (~LainExper@user/LainExperiments) LainExperiments |
| 2024-11-07 02:29:41 +0100 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 252 seconds) |
| 2024-11-07 02:26:35 +0100 | LainExperiments | (~LainExper@user/LainExperiments) (Quit: Client closed) |
| 2024-11-07 02:25:25 +0100 | <geekosaur> | synchronous exceptions were a fundamental mistake |
| 2024-11-07 02:25:11 +0100 | <geekosaur> | you're likely to leak with any exception |
| 2024-11-07 02:25:09 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 260 seconds) |
| 2024-11-07 02:24:54 +0100 | <geekosaur> | https://mail.haskell.org/pipermail/libraries/2014-September/023675.html |
| 2024-11-07 02:23:48 +0100 | <dolio> | That's very naive. |
| 2024-11-07 02:22:40 +0100 | <geekosaur> | as long as exceptions are a trainwreck, I can't see it being worse |
| 2024-11-07 02:21:01 +0100 | <dolio> | Well, you could restructure everything to return explicit failures. However, the problem is that that isn't necessarily a good idea. |
| 2024-11-07 02:20:06 +0100 | <geekosaur> | no, they're actual exceptions that must be caught in `IO` with `catch` or `handle` etc. |
| 2024-11-07 02:17:47 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-11-07 02:16:08 +0100 | ljdarj | (~Thunderbi@user/ljdarj) (Ping timeout: 272 seconds) |
| 2024-11-07 02:15:09 +0100 | xff0x | (~xff0x@fsb6a9491c.tkyc517.ap.nuro.jp) |
| 2024-11-07 02:15:05 +0100 | notzmv | (~daniel@user/notzmv) notzmv |
| 2024-11-07 02:14:13 +0100 | jero98772 | (~jero98772@2800:484:1d7c:cc00::3) (Client Quit) |
| 2024-11-07 02:14:08 +0100 | jero98772 | (~jero98772@2800:484:1d7c:cc00::3) |