Newest at the top
| 2025-09-26 13:19:15 +0200 | <[exa]> | I might really want to reword the whole problem to recommendations instead of the error/exception wording, it makes interpretation much easier |
| 2025-09-26 13:18:32 +0200 | <tomsmeding> | math! |
| 2025-09-26 13:18:26 +0200 | <tomsmeding> | neat |
| 2025-09-26 13:18:13 +0200 | <[exa]> | so yeah partial order it is |
| 2025-09-26 13:18:09 +0200 | <[exa]> | I have one error where there's timeout in one service and auth failure in another, and both need to be handled (someone needs to tell admins to check credentials, and someone else needs to delay the retry), and they both occlude a few other errors/warnings |
| 2025-09-26 13:18:07 +0200 | <tomsmeding> | you still have to define your partial order of course |
| 2025-09-26 13:17:59 +0200 | <tomsmeding> | you can probably do better than O(n^2) somehow, but this may well be "good enough" |
| 2025-09-26 13:17:38 +0200 | <tomsmeding> | then you could choose to run `reduce` in the (<>) on Errors (if you make it a newtype), or you could run `reduce` at the end once only |
| 2025-09-26 13:17:12 +0200 | <tomsmeding> | perhaps a stupid slow but working version of that lattice approach is: type Errors = Set Error; then have `reduce :: Errors -> Errors` that loops over all pairs (e1, e2) in the set (i.e. it's O(n^2)) and if e1 < e2 in your partial order, then e1 is removed from the set |
| 2025-09-26 13:16:09 +0200 | <[exa]> | now if I could have more maxima, I guess interpretation is gonna be harder but it solves the issue |
| 2025-09-26 13:15:53 +0200 | <[exa]> | yeah you know what, I thought I can live with the ordering of the errors but I was hitting a problem where I didn't know what the useful maxima would be |
| 2025-09-26 13:15:22 +0200 | <tomsmeding> | lattice ~ partial order in my mind |
| 2025-09-26 13:15:12 +0200 | <tomsmeding> | if you want more detail you can either add fields to the RetryNeeded/ReconfigNeeded constructors, or instead transpose the thing and have `data Error` be the long sum type of actual fine-grained errors, and have `isRetryNeeded :: Error -> Bool` and `isReconfigNeeded :: Error -> Bool` |
| 2025-09-26 13:15:12 +0200 | <[exa]> | hm lattice |
| 2025-09-26 13:15:05 +0200 | L29Ah | (~L29Ah@wikipedia/L29Ah) L29Ah |
| 2025-09-26 13:13:45 +0200 | wootehfoot | (~wootehfoo@user/wootehfoot) (Read error: Connection reset by peer) |
| 2025-09-26 13:13:39 +0200 | <tomsmeding> | if your errors are not linearly ordered then I wonder if there's some clever kind of lattice-based deduplication algorithm you could run on the Set Error :p |
| 2025-09-26 13:12:54 +0200 | <haskellbridge> | <sm> if you can meaningfully collect and list them all, that could be another approach |
| 2025-09-26 13:11:54 +0200 | <[exa]> | so kinda scanning for possibilities |
| 2025-09-26 13:11:46 +0200 | <[exa]> | yeah I got to a situation where handing the error combinations by one is a bit to much |
| 2025-09-26 13:11:41 +0200 | trickard_ | (~trickard@cpe-50-98-47-163.wireline.com.au) |
| 2025-09-26 13:11:39 +0200 | <tomsmeding> | if you just want the maximum, type Errors = Data.Monoid.Max Error |
| 2025-09-26 13:11:07 +0200 | <haskellbridge> | <sm> [exa] I think that gets pretty complicated and a more sequential / prioritised handling of single errors can be more practical |
| 2025-09-26 13:10:56 +0200 | trickard | (~trickard@cpe-50-98-47-163.wireline.com.au) (Ping timeout: 240 seconds) |
| 2025-09-26 13:10:55 +0200 | <[exa]> | yeah that way I could do a maximum on that and just go with what's worst |
| 2025-09-26 13:10:34 +0200 | <tomsmeding> | perhaps instead data Error = RetryNeeded | ReconfigNeeded deriving (Eq, Ord); type Errors = Set Error |
| 2025-09-26 13:10:28 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 256 seconds) |
| 2025-09-26 13:10:13 +0200 | <tomsmeding> | data Error = RetryNeeded | ReconfigNeeded; type Errors = [Error] |
| 2025-09-26 13:09:49 +0200 | wootehfoot | (~wootehfoo@user/wootehfoot) wootehfoot |
| 2025-09-26 13:09:43 +0200 | <[exa]> | yeah well validation collects the errors into a semigroup (that's good) but I was kinda asking more about how to structure (and interpret) that semigroup |
| 2025-09-26 13:09:20 +0200 | <tomsmeding> | i.e. just Either but with no Monad instance, and an Applicative instance that proceeds and collects all errors instead of stopping |
| 2025-09-26 13:08:53 +0200 | <lambdabot> | https://hackage.haskell.org/package/validation |
| 2025-09-26 13:08:53 +0200 | <tomsmeding> | @hackage validation |
| 2025-09-26 13:08:31 +0200 | <tomsmeding> | [exa]: Validation? |
| 2025-09-26 13:06:37 +0200 | <[exa]> | and well ofc if there was a good functional way to model that, it would be <3 :) |
| 2025-09-26 13:05:57 +0200 | <[exa]> | maybe s/errors/recommendations/ at this point |
| 2025-09-26 13:05:50 +0200 | <[exa]> | is there some good way/approach/systematization to "combine" errors? E.g. I have 2 parts of a program, one fails in a way that looks like a retry would help, another fails in a way that suggests reconfiguration is needed. I want them to somehow automagically combine so that other parts of the program may derive e.g. if they should retry or contact admins instead |
| 2025-09-26 13:04:05 +0200 | Enrico63 | (~Enrico63@2a0b:e541:10d0:0:9efc:e8ff:fe24:3213) (Quit: Client closed) |
| 2025-09-26 13:02:55 +0200 | humasect | (~humasect@dyn-192-249-132-90.nexicom.net) (Ping timeout: 240 seconds) |
| 2025-09-26 13:00:26 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-09-26 12:58:15 +0200 | humasect | (~humasect@dyn-192-249-132-90.nexicom.net) humasect |
| 2025-09-26 12:53:57 +0200 | lortabac | (~lortabac@2a01:e0a:541:b8f0:55ab:e185:7f81:54a4) lortabac |
| 2025-09-26 12:48:58 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 248 seconds) |
| 2025-09-26 12:48:58 +0200 | Lycurgus | (~juan@user/Lycurgus) (Quit: alsoknownas.renjuan.org ( juan@acm.org )) |
| 2025-09-26 12:26:12 +0200 | humasect | (~humasect@dyn-192-249-132-90.nexicom.net) (Remote host closed the connection) |
| 2025-09-26 12:18:03 +0200 | arandombit | (~arandombi@user/arandombit) arandombit |
| 2025-09-26 12:14:15 +0200 | lortabac | (~lortabac@2a01:e0a:541:b8f0:55ab:e185:7f81:54a4) (Ping timeout: 252 seconds) |
| 2025-09-26 12:12:23 +0200 | mari-estel | (~mari-este@user/mari-estel) mari-estel |
| 2025-09-26 12:06:25 +0200 | CiaoSen | (~Jura@2a02:8071:64e1:da0:5a47:caff:fe78:33db) (Ping timeout: 250 seconds) |
| 2025-09-26 12:00:01 +0200 | lortabac | (~lortabac@2a01:e0a:541:b8f0:55ab:e185:7f81:54a4) |