Newest at the top
| 2024-07-05 18:55:44 +0200 | misterfish | (~misterfis@84.53.85.146) |
| 2024-07-05 18:53:47 +0200 | destituion | (~destituio@2a02:2121:6bc:1a95:cb10:e092:4032:88f5) |
| 2024-07-05 18:51:16 +0200 | sord937 | (~sord937@gateway/tor-sasl/sord937) (Quit: sord937) |
| 2024-07-05 18:48:34 +0200 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Ping timeout: 260 seconds) |
| 2024-07-05 18:47:08 +0200 | soverysour | (~soverysou@user/soverysour) |
| 2024-07-05 18:42:58 +0200 | <haskellbridge> | <sm> command line parsing gets tricky ! |
| 2024-07-05 18:42:08 +0200 | <danse-nr3> | \o good work |
| 2024-07-05 18:41:54 +0200 | <hololeap> | anyway, I really just wanted some advice on the uninitialized constructor idea, and I got it, so I'll get back to coding. thanks again! |
| 2024-07-05 18:40:59 +0200 | vpan | (~vpan@212.117.1.172) (Quit: Leaving.) |
| 2024-07-05 18:39:08 +0200 | <hololeap> | it also has the requirement of only depending on packages that come bundled with GHC, so for optparse-applicative esque commands, I'd have to roll my own |
| 2024-07-05 18:38:37 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) |
| 2024-07-05 18:38:20 +0200 | euleritian | (~euleritia@dynamic-176-002-131-122.176.2.pool.telefonica.de) (Read error: Connection reset by peer) |
| 2024-07-05 18:37:32 +0200 | <hololeap> | true, but it's an old open source utility that I'm working on, so I'm sort of evolving it slowly in the direction it needs to go, rather than just rewriting it, partially because I'm dogfooding it and assessing things as I go. the feature drift is a bit of a necessary evil at this point, and keeping the command line similar to what it has been in the past is a priority just so I don't confuse current users of it |
| 2024-07-05 18:34:37 +0200 | <danse-nr3> | once you can get a top level sum type, for instance, that paves the path towards eventually splitting commands into separate concerns |
| 2024-07-05 18:33:24 +0200 | <danse-nr3> | it's three types where i would personally wish to have just one that makes sense. Arguments interacting with each other in a fairly complex way is probably not the best usability |
| 2024-07-05 18:33:19 +0200 | <hololeap> | thanks for the insights c_wraith, danse-nr3 |
| 2024-07-05 18:32:05 +0200 | <hololeap> | anyway, I think the most straightforward thing to do here is to move step 3 to the same modules where the work is being done |
| 2024-07-05 18:31:08 +0200 | <hololeap> | danse-nr3: to some degree, yes. it's a CLI program and the way that arguments interact with each other is fairly complex, so I have it separated into: 1) a model of the possible command line options given by the user 2) conversion/parsing/validation to an ADT of possible valid modes of the program 3) conversion of this ADT to types that control the behavior of other parts that are doing the actual work |
| 2024-07-05 18:31:03 +0200 | <c_wraith> | If I'm getting a lot of ad-hoc types out of that, it's time to consider refactoring so that the cases all follow clearly-delineated patterns |
| 2024-07-05 18:30:04 +0200 | destituion | (~destituio@2a02:2121:6bc:1a95:cb10:e092:4032:88f5) (Remote host closed the connection) |
| 2024-07-05 18:29:44 +0200 | <c_wraith> | in the end, I just create new types for new cases. If all I know are these three fields, I dig into *why* that's true, then create a new data type that contains those three fields and document when it's the right thing to use. |
| 2024-07-05 18:29:26 +0200 | destituion | (~destituio@2a02:2121:6bc:1a95:cb10:e092:4032:88f5) |
| 2024-07-05 18:29:16 +0200 | rdcdr | (~rdcdr@user/rdcdr) (Quit: ZNC 1.8.2+deb3.1 - https://znc.in) |
| 2024-07-05 18:29:07 +0200 | akira-sijk | (~akira-sij@27.47.33.155) () |
| 2024-07-05 18:28:46 +0200 | soverysour | (~soverysou@user/soverysour) (Ping timeout: 264 seconds) |
| 2024-07-05 18:28:42 +0200 | <hololeap> | good points |
| 2024-07-05 18:28:16 +0200 | <c_wraith> | hololeap: But I'm overall unimpressed with the barbies-like approaches as well. I find they really lack the granularity to express "I know these three fields, but not those five" |
| 2024-07-05 18:27:33 +0200 | <danse-nr3> | but also it sounds like a problem in organising dependencies. This big ADT type is made of smaller types i guess. Do conversions need to take the whole ADT in order to produce what is modularly needed? |
| 2024-07-05 18:26:45 +0200 | akira-sijk | (~akira-sij@27.47.33.155) |
| 2024-07-05 18:25:58 +0200 | <c_wraith> | hololeap: In some sense it's bad for type safety to make uninitialized values the same type as usable values. |
| 2024-07-05 18:25:53 +0200 | <danse-nr3> | if not deceptive |
| 2024-07-05 18:25:07 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2024-07-05 18:24:44 +0200 | <danse-nr3> | that would just be misleading |
| 2024-07-05 18:24:23 +0200 | <haskellbridge> | <thirdofmay18081814goya> * instances of bits of haskell code that follow best practices according to whoever |
| 2024-07-05 18:24:12 +0200 | <hololeap> | hope that made sense |
| 2024-07-05 18:24:07 +0200 | <haskellbridge> | <thirdofmay18081814goya> danse-nr3: personal preferences, instance of bits of haskell code that follow best practices |
| 2024-07-05 18:23:35 +0200 | tomku | (~tomku@syn-141-126-184-057.res.spectrum.com) |
| 2024-07-05 18:23:10 +0200 | <hololeap> | it's not really a "problem" I'm trying to solve, just painting myself into a corner with the way I'm organizing things :p |
| 2024-07-05 18:22:22 +0200 | <hololeap> | constructors |
| 2024-07-05 18:22:22 +0200 | <hololeap> | the way I have this program organized is to have a big ADT in its own module that represents all the valid modes of the program, and the actual work being done is separated into other modules. my original idea was to have the ADT module also include conversion functions that translate the ADT to types that are specialized for the other parts of the code. however the ADT module does not contain any of the code necessary to fill in the blanks for these |
| 2024-07-05 18:21:58 +0200 | tomku | (~tomku@syn-141-126-184-057.res.spectrum.com) (Ping timeout: 268 seconds) |
| 2024-07-05 18:21:57 +0200 | <c_wraith> | hololeap: like, talking about uninitialized states makes me think you're trying to avoid having different data types for request/response to some api. Is that even remotely close? |
| 2024-07-05 18:21:29 +0200 | <danse-nr3> | how can they "exemplify good haskell" when, by being very small, they would include just a fraction of it? |
| 2024-07-05 18:20:28 +0200 | <haskellbridge> | <thirdofmay18081814goya> what are some very small haskell repositories that exemplify good haskell |
| 2024-07-05 18:19:51 +0200 | <danse-nr3> | for Either Int Int, for instance, you can have one function opting for Left and Right and another function providing the Int, just to make a silly example about what you described |
| 2024-07-05 18:18:05 +0200 | <c_wraith> | well I understand what you're suggesting as a solution. But I don't understand the problem you're suggesting it as a solution to |
| 2024-07-05 18:17:35 +0200 | <hololeap> | c_wraith: it sounds like you do |
| 2024-07-05 18:17:29 +0200 | <danse-nr3> | me neither |
| 2024-07-05 18:17:25 +0200 | <c_wraith> | I still don't really understand what you want. |
| 2024-07-05 18:17:24 +0200 | qqe | (~qqq@92.43.167.61) (Ping timeout: 255 seconds) |