Logs: liberachat/#haskell
| 2025-12-27 14:59:48 | <haskellbridge> | <Zemyla> I read this article, and Ryan forgot one option. https://ryanglscott.github.io/2019/02/06/proxy-arguments-in-class-methods/ |
| 2025-12-27 15:00:34 | <haskellbridge> | <Zemyla> metaData :: Const blah a (or Tagged a blah) |
| 2025-12-27 15:00:55 | × | merijn quits (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 264 seconds) |
| 2025-12-27 15:01:42 | <haskellbridge> | <Zemyla> It has most of the pros of the "no explicit arguments", including the fact that it's not a function which can matter for performance. But it doesn't require language extensions. |
| 2025-12-27 15:03:07 | <haskellbridge> | <Liamzee> i guess FFI isn't that simple, ugh, but it's more cabal's fault |
| 2025-12-27 15:10:19 | → | merijn joins (~merijn@62.45.136.136) |
| 2025-12-27 15:15:15 | × | merijn quits (~merijn@62.45.136.136) (Ping timeout: 252 seconds) |
| 2025-12-27 15:22:13 | × | pabs3 quits (~pabs3@user/pabs3) (Quit: Don't rest until all the world is paved in moss and greenery.) |
| 2025-12-27 15:24:18 | → | pabs3 joins (~pabs3@user/pabs3) |
| 2025-12-27 15:26:03 | → | merijn joins (~merijn@host-cl.cgnat-g.v4.dfn.nl) |
| 2025-12-27 15:30:15 | × | wootehfoot quits (~wootehfoo@user/wootehfoot) (Ping timeout: 240 seconds) |
| 2025-12-27 15:31:13 | × | merijn quits (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 264 seconds) |
| 2025-12-27 15:41:51 | → | merijn joins (~merijn@host-cl.cgnat-g.v4.dfn.nl) |
| 2025-12-27 15:42:29 | × | raym quits (~ray@user/raym) (Quit: leaving) |
| 2025-12-27 15:48:32 | × | merijn quits (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 240 seconds) |
| 2025-12-27 15:59:55 | → | merijn joins (~merijn@host-cl.cgnat-g.v4.dfn.nl) |
| 2025-12-27 16:03:28 | × | rainbyte quits (~rainbyte@186.22.19.214) (Read error: Connection reset by peer) |
| 2025-12-27 16:05:00 | → | rainbyte joins (~rainbyte@186.22.19.214) |
| 2025-12-27 16:05:01 | × | merijn quits (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 256 seconds) |
| 2025-12-27 16:11:15 | → | merijn joins (~merijn@host-cl.cgnat-g.v4.dfn.nl) |
| 2025-12-27 16:12:33 | <ncf> | edwardk: in Data.Distributive you wrote that "Categorically every Distributive functor is actually a right adjoint". do you have a proof of this somewhere? |
| 2025-12-27 16:13:15 | <ncf> | at least i don't think one can prove this "internally", as in write an instance Distributive g => Representable g |
| 2025-12-27 16:16:10 | × | merijn quits (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 245 seconds) |
| 2025-12-27 16:17:00 | × | m1dnight quits (~m1dnight@d8D861A17.access.telenet.be) (Ping timeout: 245 seconds) |
| 2025-12-27 16:19:18 | <haskellbridge> | <Zemyla> Actually, a "generic" Rep type is newtype GRep g = GRep { runGRep :: forall a. g a -> a } I remember reading an article about it. |
| 2025-12-27 16:20:19 | <haskellbridge> | <Zemyla> You can use collect somehow to make g (g Any -> Any), then fmap unsafeCoerce to g (GRep g), which is safe because of parametricity. |
| 2025-12-27 16:20:37 | <haskellbridge> | <Zemyla> And that's basically the id function for a representable. |
| 2025-12-27 16:22:41 | <haskellbridge> | <Zemyla> https://duplode.github.io/posts/every-distributive-is-representable.html |
| 2025-12-27 16:23:04 | <ncf> | thanks |
| 2025-12-27 16:26:43 | → | sroso joins (~sroso@user/SrOso) |
| 2025-12-27 16:27:00 | → | merijn joins (~merijn@host-cl.cgnat-g.v4.dfn.nl) |
| 2025-12-27 16:31:43 | × | merijn quits (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 240 seconds) |
| 2025-12-27 16:35:22 | → | ttybitnik joins (~ttybitnik@user/wolper) |
| 2025-12-27 16:42:44 | → | merijn joins (~merijn@host-cl.cgnat-g.v4.dfn.nl) |
| 2025-12-27 16:45:30 | ← | L29Ah parts (~L29Ah@wikipedia/L29Ah) () |
| 2025-12-27 16:48:09 | × | merijn quits (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 260 seconds) |
| 2025-12-27 16:50:20 | × | annamalai quits (~annamalai@157.32.132.241) (Ping timeout: 245 seconds) |
| 2025-12-27 16:57:06 | → | m1dnight joins (~m1dnight@d8D861A17.access.telenet.be) |
| 2025-12-27 16:58:03 | × | CiaoSen quits (~Jura@2a02:8071:64e1:da0:5a47:caff:fe78:33db) (Ping timeout: 260 seconds) |
| 2025-12-27 16:58:31 | → | merijn joins (~merijn@host-cl.cgnat-g.v4.dfn.nl) |
| 2025-12-27 17:03:53 | × | merijn quits (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 260 seconds) |
| 2025-12-27 17:11:16 | → | Everything joins (~Everythin@172-232-54-192.ip.linodeusercontent.com) |
| 2025-12-27 17:12:14 | → | merijn joins (~merijn@host-cl.cgnat-g.v4.dfn.nl) |
| 2025-12-27 17:18:58 | × | merijn quits (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 255 seconds) |
| 2025-12-27 17:20:00 | → | annamalai joins (~annamalai@157.32.142.174) |
| 2025-12-27 17:20:50 | × | annamalai quits (~annamalai@157.32.142.174) (Remote host closed the connection) |
| 2025-12-27 17:21:09 | → | annamalai joins (~annamalai@157.32.142.174) |
| 2025-12-27 17:29:50 | <haskellbridge> | <Liamzee> life is fun, now i'm deliberately trying to vibecode segfaults on a Apple Silicon Mac |
| 2025-12-27 17:30:17 | → | merijn joins (~merijn@host-cl.cgnat-g.v4.dfn.nl) |
| 2025-12-27 17:30:32 | <pie_> | this is really basic but i never understood how to do error handling in software properly |
| 2025-12-27 17:30:32 | <pie_> | beyond the equivalent of catching an error and doing nothing with it or putting a todo there or something |
| 2025-12-27 17:30:32 | <pie_> | ok maybe today if i thought about it i could do a little better; just crash the program if you run into an issue (which is what happens when you dont catch an exception i guess) |
| 2025-12-27 17:30:32 | <pie_> | but like how do you do stuff properly if you dont want your programs to just fail |
| 2025-12-27 17:30:32 | <pie_> | (alternatively, what do i read on this) |
| 2025-12-27 17:30:52 | <pie_> | so like, what does "good error handling design" look like in software engineering? |
| 2025-12-27 17:31:40 | <monochrom> | In many cases, there is a reasonable plan B. The details depends on the actual code and/or the actual specification. |
| 2025-12-27 17:31:52 | <pie_> | ok sure i guess some of the stuff you would start with is the difference between invalid programs, and runtime errors / that you want to fail fast to prevent invalid state propagation, .. |
| 2025-12-27 17:33:49 | → | wennefer0_______ joins (~wennefer0@user/wennefer0) |
| 2025-12-27 17:34:18 | <pie_> | what if i dont want my programs to crash? (put a restarting wrapper around it? - so like presumably whatever erlang does i guess?) |
| 2025-12-27 17:34:34 | <pie_> | i wouldnt mind if i could read up on a thorough discussion of these kinds of things |
| 2025-12-27 17:34:47 | <pie_> | idk, what do they do in embedded space software or whatever |
| 2025-12-27 17:34:54 | <pie_> | just remove all the errors? :P |
| 2025-12-27 17:34:55 | × | merijn quits (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 240 seconds) |
| 2025-12-27 17:35:25 | <pie_> | *design out all the errors its designed to handle, fall back to remote external intervention for whatever else |
| 2025-12-27 17:37:55 | × | wennefer0_______ quits (~wennefer0@user/wennefer0) (Ping timeout: 240 seconds) |
| 2025-12-27 17:38:17 | → | ystael joins (~ystael@user/ystael) |
| 2025-12-27 17:46:02 | → | merijn joins (~merijn@host-cl.cgnat-g.v4.dfn.nl) |
| 2025-12-27 17:51:01 | × | merijn quits (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 264 seconds) |
| 2025-12-27 18:01:07 | → | merijn joins (~merijn@host-cl.cgnat-g.v4.dfn.nl) |
| 2025-12-27 18:05:31 | <pie_> | watched most of this (2x) and i also largely agree with the question being asked, but it doesnt really provide much in terms of solutions i think. https://www.youtube.com/watch?v=ZUAPHTbxnAc The Absurdity of Error Handling: Finding a Purpose for Errors in Safety-Critical SYCL - Erik Tomusk |
| 2025-12-27 18:06:27 | × | merijn quits (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 265 seconds) |
| 2025-12-27 18:08:47 | → | wootehfoot joins (~wootehfoo@user/wootehfoot) |
| 2025-12-27 18:09:14 | <monochrom> | The scenerio I'm most familiar with is that the user gives you a filename and you open it to do your job. We anticipate that sometimes the open attempt fails. For a non-interactive command line program, you pretty have no choice but give up and exit. For a GUI though, you can and should always catch the exception, tell the user, and be ready to take another filename and try again. |
| 2025-12-27 18:10:07 | × | synchromesh quits (~john@2406:5a00:2412:2c00:694d:f25a:3b3c:f3f9) (Read error: Connection reset by peer) |
| 2025-12-27 18:10:56 | <pie_> | the short of the video is that safe systems from a language designer POV are about removing undefined behavior from a language, from a practitioner viewpoint are about determinism, and error handling is about moving the application from an unintended state back to an intended state, and the question is (well not the way im phrasing it) that the overlap between understood state and error state is so small or nonexistent enough that "does error handling |
| 2025-12-27 18:10:56 | <pie_> | even make sense?" - something like that |
| 2025-12-27 18:11:18 | → | synchromesh joins (~john@2406:5a00:2412:2c00:694d:f25a:3b3c:f3f9) |
| 2025-12-27 18:11:54 | <monochrom> | But taking a step back, those are just logical conclusions of the respective specifications. The first case has already required non-interactiveness, so you can only give up. The second case has already specified a GUI, implying that you never exit unless the user tells you to. It is common sense, there is no need to read a book about it. |
| 2025-12-27 18:12:07 | → | __monty__ joins (~toonn@user/toonn) |
| 2025-12-27 18:13:15 | → | merijn joins (~merijn@host-cl.cgnat-g.v4.dfn.nl) |
| 2025-12-27 18:13:47 | <pie_> | well, its not so obvious to my puny brain |
| 2025-12-27 18:13:53 | <pie_> | but if you explain it that way, sure |
| 2025-12-27 18:14:20 | <pie_> | like yes ive seen gui applications that pop up an exception window (for stuff thats not the failure to open a file) and let you try to continue anyway |
| 2025-12-27 18:14:30 | <pie_> | and ok for cli applications |
| 2025-12-27 18:14:37 | <pie_> | makes sense |
| 2025-12-27 18:14:46 | <pie_> | but i guess i was implicitly also thinking about things like services |
| 2025-12-27 18:17:03 | <monochrom> | Another scenerio is much more complex but also a solved problem so you should not re-invent the wheel. Relational databases, transactions, and the choice to rollback a transaction (because you detect an invalidity). |
| 2025-12-27 18:18:07 | → | ss4 joins (~wootehfoo@user/wootehfoot) |
| 2025-12-27 18:18:13 | × | merijn quits (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 250 seconds) |
| 2025-12-27 18:18:41 | <monochrom> | That would be when an error in the middle of something causes invalid states. The solution is to undo that unfinished something. |
| 2025-12-27 18:19:50 | <monochrom> | Easier said than done, sure. That's why you outsource it to a mature relational database, rather than bothering to code up your own. |
| 2025-12-27 18:20:54 | <monochrom> | Alterantively use Haskell's STM. :) |
| 2025-12-27 18:21:41 | × | wootehfoot quits (~wootehfoo@user/wootehfoot) (Ping timeout: 250 seconds) |
| 2025-12-27 18:21:57 | <pie_> | im too dumb to reinvent the wheel, thats why im asking :> |
| 2025-12-27 18:22:11 | <sm> | pie_ , you're on the right track - it's good to think about the kinds of errors and how you want to handle each; there are multiple error handling strategies. |
| 2025-12-27 18:22:27 | <sm> | also, Erlang is an excellent thing to read about |
| 2025-12-27 18:24:40 | <sm> | it is the best exemplar of the "monitor subsystems and restart them when they fail" strategy |
| 2025-12-27 18:29:01 | → | merijn joins (~merijn@host-cl.cgnat-g.v4.dfn.nl) |
| 2025-12-27 18:34:02 | × | merijn quits (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 256 seconds) |
| 2025-12-27 18:36:28 | → | wootehfoot joins (~wootehfoo@user/wootehfoot) |
All times are in UTC.