Newest at the top
| 2025-11-14 22:03:51 +0100 | djspacewhale | (~djspacewh@user/djspacewhale) (Remote host closed the connection) |
| 2025-11-14 22:01:25 +0100 | deptype | (~deptype@2406:b400:3a:73c2:6877:dc6f:cb6b:d011) |
| 2025-11-14 22:01:12 +0100 | deptype | (~deptype@2406:b400:3a:73c2:cdc4:150f:4f12:1dd1) (Remote host closed the connection) |
| 2025-11-14 21:58:48 +0100 | <davean> | Thats litterly how they're a problem |
| 2025-11-14 21:58:28 +0100 | <davean> | We only have referntial transparency in a few respects, not all. |
| 2025-11-14 21:58:16 +0100 | <dolio> | Like, if bounds checked array access causes the result to be a Maybe, that's extra bad. |
| 2025-11-14 21:57:56 +0100 | gentauro | (~gentauro@user/gentauro) gentauro |
| 2025-11-14 21:57:56 +0100 | gentauro | (~gentauro@91.226.144.99) (Changing host) |
| 2025-11-14 21:57:54 +0100 | <davean> | loonycyborg: We *already lack referential transparency* because of the non-determinism of exceptions. |
| 2025-11-14 21:57:11 +0100 | gentauro_ | gentauro |
| 2025-11-14 21:57:07 +0100 | td_ | (~td@i5387092A.versanet.de) |
| 2025-11-14 21:56:53 +0100 | <dolio> | Anyhow, the point isn't really to catch those kind of exceptions. The point is that some pure-ish code wants to use exceptions, but having them return `Either` or `Maybe` for that is a bad implementation. |
| 2025-11-14 21:56:46 +0100 | Fijxu_ | (~Fijxu@user/fijxu) fijxu |
| 2025-11-14 21:55:37 +0100 | haltingsolver | (~cmo@2604:3d09:207f:8000::d1dc) |
| 2025-11-14 21:55:11 +0100 | td_ | (~td@i53870933.versanet.de) (Ping timeout: 256 seconds) |
| 2025-11-14 21:54:37 +0100 | humasect | (~humasect@dyn-192-249-132-90.nexicom.net) (Ping timeout: 264 seconds) |
| 2025-11-14 21:54:09 +0100 | <dolio> | If you handle an OOM error in pure code, maybe some memory has already been freed so it's no longer a problem. :) |
| 2025-11-14 21:52:58 +0100 | humasect_ | (~humasect@dyn-192-249-132-90.nexicom.net) (Remote host closed the connection) |
| 2025-11-14 21:52:45 +0100 | humasect_ | (~humasect@dyn-192-249-132-90.nexicom.net) humasect |
| 2025-11-14 21:51:23 +0100 | tomsmeding | forces fgarcia's thunk |
| 2025-11-14 21:51:12 +0100 | djspacewhale | (~djspacewh@user/djspacewhale) djspacewhale |
| 2025-11-14 21:49:04 +0100 | humasect | (~humasect@dyn-192-249-132-90.nexicom.net) humasect |
| 2025-11-14 21:48:48 +0100 | humasect | (~humasect@dyn-192-249-132-90.nexicom.net) (Read error: Connection reset by peer) |
| 2025-11-14 21:47:52 +0100 | fgarcia | causes a thunk |
| 2025-11-14 21:47:49 +0100 | fp | (~Thunderbi@2001-14ba-6e24-3000--19a.rev.dnainternet.fi) (Quit: fp) |
| 2025-11-14 21:44:51 +0100 | karenw | (~karenw@user/karenw) karenw |
| 2025-11-14 21:40:53 +0100 | deptype | (~deptype@2406:b400:3a:73c2:cdc4:150f:4f12:1dd1) |
| 2025-11-14 21:40:40 +0100 | deptype | (~deptype@2406:b400:3a:73c2:566e:3c9f:8ac3:f831) (Remote host closed the connection) |
| 2025-11-14 21:35:41 +0100 | target_i | (~target_i@user/target-i/x-6023099) target_i |
| 2025-11-14 21:34:42 +0100 | eron | (~eron@187.56.155.181) (Quit: Client closed) |
| 2025-11-14 21:29:53 +0100 | <haskellbridge> | <Zemyla> Yeah, it'd definitely be a different language, one more like Rust. |
| 2025-11-14 21:20:50 +0100 | deptype | (~deptype@2406:b400:3a:73c2:566e:3c9f:8ac3:f831) |
| 2025-11-14 21:20:35 +0100 | deptype | (~deptype@2406:b400:3a:73c2:10ea:4f19:b27b:3bbc) (Remote host closed the connection) |
| 2025-11-14 21:16:13 +0100 | Square3 | (~Square@user/square) (Ping timeout: 264 seconds) |
| 2025-11-14 21:16:06 +0100 | polykernel_ | polykernel |
| 2025-11-14 21:16:06 +0100 | polykernel | (~polykerne@user/polykernel) (Ping timeout: 256 seconds) |
| 2025-11-14 21:14:12 +0100 | shr\ke | (~shrike@user/shrke:31298) shr\ke |
| 2025-11-14 21:14:12 +0100 | shr\ke | (~shrike@user/paxhumana) (Changing host) |
| 2025-11-14 21:14:12 +0100 | shr\ke | (~shrike@user/paxhumana) paxhumana |
| 2025-11-14 21:13:53 +0100 | polykernel_ | (~polykerne@user/polykernel) polykernel |
| 2025-11-14 21:13:03 +0100 | Lycurgus | (~juan@user/Lycurgus) (Quit: alsoknownas.renjuan.org ( juan@acm.org )) |
| 2025-11-14 21:11:47 +0100 | humasect | (~humasect@dyn-192-249-132-90.nexicom.net) humasect |
| 2025-11-14 21:08:42 +0100 | CiaoSen | (~Jura@2a02:8071:64e1:da0:5a47:caff:fe78:33db) CiaoSen |
| 2025-11-14 21:07:10 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-11-14 21:06:47 +0100 | <EvanR> | maximum number of elements submitted in the request |
| 2025-11-14 21:06:31 +0100 | fp | (~Thunderbi@2001-14ba-6e24-3000--19a.rev.dnainternet.fi) fp |
| 2025-11-14 21:06:26 +0100 | <EvanR> | maximum request body, maximum numeric field values, assuming the body can be decoded, which itself has limits baked into the parser |
| 2025-11-14 21:05:20 +0100 | <EvanR> | it sounds infeasible until you think about how a web service handler is defacto designed with a whole page of limits and guardrails |
| 2025-11-14 21:04:12 +0100 | <EvanR> | a simple version would simply not run a program known to need X memory if you can't reserve X memory at startup |
| 2025-11-14 21:03:32 +0100 | <EvanR> | tracking memory usage in the type system is a possibility. Probably not in haskell which relies heavily on allocating willy nilly |