Newest at the top
| 2024-07-05 20:27:14 +0200 | <jle`> | hi! i have been floating in and out for the past few months heh |
| 2024-07-05 20:26:37 +0200 | <haskellbridge> | <iqubic (she/her)> Jle`: You're back!!! |
| 2024-07-05 20:26:00 +0200 | <jle`> | was there a recent ghc version where $$(myTH) can now be written as $$myTH ? or was it always permitted and i just didn't know |
| 2024-07-05 20:21:46 +0200 | Lord_of_Life_ | Lord_of_Life |
| 2024-07-05 20:21:09 +0200 | noumenon | (~noumenon@2a01:799:cd8:e700:aa7e:eaff:fede:ff94) |
| 2024-07-05 20:19:10 +0200 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) (Ping timeout: 246 seconds) |
| 2024-07-05 20:18:49 +0200 | Lord_of_Life_ | (~Lord@user/lord-of-life/x-2819915) |
| 2024-07-05 20:17:52 +0200 | <haskellbridge> | <iqubic (she/her)> Overloaded strings are pretty OP. |
| 2024-07-05 20:17:19 +0200 | <probie> | Inst: "foo :: Text" is the same as if you'd written "(fromString "foo") :: Text", however that doesn't actually mean there will be a `String` in the compiled code. GHC normally does a very good job optimising it all away and just leaving you with the `Text` value you'd expect |
| 2024-07-05 20:16:04 +0200 | <haskellbridge> | <iqubic (she/her)> What do people recommend for generating random values? I know that some of this stuff will have to be in IO, but I think most of the functions can be pure by doing something like "generator -> (Int, generator)" |
| 2024-07-05 20:15:17 +0200 | fun-safe-math | (~fun-safe-@24.21.106.247) |
| 2024-07-05 20:15:07 +0200 | soverysour | (~soverysou@user/soverysour) (Ping timeout: 268 seconds) |
| 2024-07-05 20:13:00 +0200 | rdcdr | (~rdcdr@user/rdcdr) (Quit: ZNC 1.8.2+deb3.1 - https://znc.in) |
| 2024-07-05 20:02:22 +0200 | <geekosaur> | much as it does for numeric literals (fromInteger/fromRational) |
| 2024-07-05 20:02:01 +0200 | <geekosaur> | it compiles them to fromString/fromList called on a normal string/list |
| 2024-07-05 20:00:36 +0200 | nurupo | (~nurupo.ga@user/nurupo) |
| 2024-07-05 20:00:17 +0200 | nurupo | (~nurupo.ga@user/nurupo) (Quit: nurupo.ga) |
| 2024-07-05 19:57:40 +0200 | <Inst> | just curious, when you have isString or isList typeclasses, are these hardcoded literals or, when GHC gets to the literals, it generates a String or List and does the conversion as needed? |
| 2024-07-05 19:57:10 +0200 | Inst | (~Inst@user/Inst) |
| 2024-07-05 19:52:31 +0200 | danse-nr3 | (~danse-nr3@151.47.148.201) (Quit: Leaving) |
| 2024-07-05 19:47:53 +0200 | rdcdr | (~rdcdr@user/rdcdr) |
| 2024-07-05 19:41:31 +0200 | codaraxis__ | (~codaraxis@user/codaraxis) (Ping timeout: 268 seconds) |
| 2024-07-05 19:37:29 +0200 | codaraxis___ | (~codaraxis@user/codaraxis) |
| 2024-07-05 19:35:59 +0200 | madhavanmiui | (~madhavanm@2409:40f4:304d:5ad7:8000::) (Client Quit) |
| 2024-07-05 19:35:18 +0200 | madhavanmiui | (~madhavanm@2409:40f4:304d:5ad7:8000::) |
| 2024-07-05 19:32:33 +0200 | L29Ah | (~L29Ah@wikipedia/L29Ah) () |
| 2024-07-05 19:20:14 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2024-07-05 19:12:29 +0200 | pavonia | (~user@user/siracusa) (Quit: Bye!) |
| 2024-07-05 19:06:33 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 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. |