Newest at the top
| 2025-05-02 20:39:09 +0200 | <EvanR> | why are you passing the config in more than 1 time |
| 2025-05-02 20:39:07 +0200 | <haskellbridge> | <Liamzee> that is giving me an anxiety attack |
| 2025-05-02 20:39:05 +0200 | <hellwolf> | :quote spiritually mutable - Liamzu |
| 2025-05-02 20:38:52 +0200 | <haskellbridge> | <Liamzee> well, change it |
| 2025-05-02 20:38:44 +0200 | <haskellbridge> | <Liamzee> if you expose the constructors to the config record, you can mutate it |
| 2025-05-02 20:38:37 +0200 | <EvanR> | that makes no sense |
| 2025-05-02 20:38:33 +0200 | <haskellbridge> | <Liamzee> spiritually mutable |
| 2025-05-02 20:38:25 +0200 | <EvanR> | why is the config mutable |
| 2025-05-02 20:38:18 +0200 | <haskellbridge> | <Liamzee> the config is mutable so i feel like it's ick |
| 2025-05-02 20:38:12 +0200 | <EvanR> | no reason to do that via IO refs |
| 2025-05-02 20:38:10 +0200 | <haskellbridge> | <Liamzee> fully expanded, it's like 16 arguments |
| 2025-05-02 20:38:04 +0200 | <EvanR> | so pass in a config |
| 2025-05-02 20:37:56 +0200 | <haskellbridge> | <Liamzee> you see why i want to pack a config instead? |
| 2025-05-02 20:37:49 +0200 | <haskellbridge> | <Liamzee> then you feed it passwords, hashes, usernames, emails, etc |
| 2025-05-02 20:37:40 +0200 | <haskellbridge> | <Liamzee> right now, i need database settings, as well as settings for what tablenames you want and potentially field names |
| 2025-05-02 20:37:09 +0200 | <haskellbridge> | <Liamzee> i'm just trying to do that bad idea, hasql login backend as a library |
| 2025-05-02 20:36:20 +0200 | <EvanR> | so I don't think the problem description was very good |
| 2025-05-02 20:36:07 +0200 | <haskellbridge> | <sm> it's not always the most convenient, but when it's inconvenient it's forcing you to clarify your program's data flows |
| 2025-05-02 20:35:52 +0200 | <EvanR> | and passing any other state would be broken |
| 2025-05-02 20:35:39 +0200 | <EvanR> | perhaps the implicitness is that your library returns some kind of state that needs to be returned to it to do anything else |
| 2025-05-02 20:35:05 +0200 | <haskellbridge> | <sm> I would say it's the simplest and least error prone, and you can reduce verbosity by bundling args into larger values |
| 2025-05-02 20:34:39 +0200 | <EvanR> | so there's gotta be some unspoken complication |
| 2025-05-02 20:34:36 +0200 | <haskellbridge> | <Liamzee> verbose and error prone, no? |
| 2025-05-02 20:34:33 +0200 | <EvanR> | pass it as a normal argument |
| 2025-05-02 20:34:23 +0200 | <haskellbridge> | <sm> what's wrong with passing arguments ? |
| 2025-05-02 20:34:22 +0200 | <haskellbridge> | <Liamzee> i feel like ocaml functors might solve this problem |
| 2025-05-02 20:34:17 +0200 | <EvanR> | taking literally what you're saying, the requirement of passing in settings and a login to a thing, that is literally just a function |
| 2025-05-02 20:33:51 +0200 | <haskellbridge> | <Liamzee> but that's smelly |
| 2025-05-02 20:33:30 +0200 | <haskellbridge> | <Liamzee> i mean since the mutability is intended as one-time, and it's IO anyways, it's not like I can't tell people to IORef it |
| 2025-05-02 20:32:39 +0200 | <haskellbridge> | <Liamzee> the user wants to plug in two things, database settings, including a login, possibly from a config file |
| 2025-05-02 20:32:30 +0200 | <EvanR> | I guess that trick has become forgotten lore |
| 2025-05-02 20:32:11 +0200 | wootehfoot | (~wootehfoo@user/wootehfoot) (Read error: Connection reset by peer) |
| 2025-05-02 20:32:08 +0200 | <haskellbridge> | <Liamzee> reflection? |
| 2025-05-02 20:31:58 +0200 | j1n37 | (~j1n37@user/j1n37) (Ping timeout: 252 seconds) |
| 2025-05-02 20:31:45 +0200 | j1n37- | (~j1n37@user/j1n37) j1n37 |
| 2025-05-02 20:31:03 +0200 | EvanR | hides |
| 2025-05-02 20:31:02 +0200 | <haskellbridge> | <Liamzee> i mean tbh i could do it via TH |
| 2025-05-02 20:30:58 +0200 | <EvanR> | reflection |
| 2025-05-02 20:30:19 +0200 | <haskellbridge> | <Liamzee> here's a problem i have, basically, let's say, i want to pass configs to a library |
| 2025-05-02 20:28:40 +0200 | Putin | alethkit |
| 2025-05-02 20:28:27 +0200 | alethkit | Putin |
| 2025-05-02 20:27:47 +0200 | dsrt^ | (ceuasyyyl@c-71-199-187-173.hsd1.ga.comcast.net) |
| 2025-05-02 20:25:13 +0200 | <monochrom> | That is very neat. |
| 2025-05-02 20:23:49 +0200 | <EvanR> | bag of errors |
| 2025-05-02 20:23:18 +0200 | <dminuoso> | In any way you want by just supplying your own function `e -> e -> e` |
| 2025-05-02 20:23:13 +0200 | todi | (~todi@183.96.168.66) todi |
| 2025-05-02 20:22:57 +0200 | <dminuoso> | You can literally build up error context level by level this way. |
| 2025-05-02 20:22:39 +0200 | <dminuoso> | For very rich error reporting, explaining the context (say to report surrounding text, or what it is you were trying to parse, or why you were trying to parse it in the first place) |
| 2025-05-02 20:21:53 +0200 | <dminuoso> | Which allows you to build up context when errors occur. |
| 2025-05-02 20:21:44 +0200 | <dminuoso> | The really cool thing here is that error merge function in cutting. |