Newest at the top
| 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) |
| 2024-07-05 18:16:59 +0200 | <hololeap> | just spitballing ideas |
| 2024-07-05 18:16:47 +0200 | <hololeap> | ok, it's probably best then to choose the constructor in the same module that is filling in the data |
| 2024-07-05 18:15:52 +0200 | <c_wraith> | also, that doesn't always work. There are constructors with strict fields. |
| 2024-07-05 18:15:46 +0200 | <hololeap> | I also know of e.g. barbies which would give a way to have the same data structures in uninitialized/initialized states, but it feels like overkill |
| 2024-07-05 18:15:07 +0200 | <c_wraith> | there is probably a better way for most use cases. |
| 2024-07-05 18:13:49 +0200 | <hololeap> | is it considered bad practice to pass a non-unary constructor around with "undefined" where the data should be? I was considering doing this so that one module decides which constructor is used, then another module fills in the blanks in a "case" statement |
| 2024-07-05 18:13:33 +0200 | robotsnowfall | (~robotsnow@user/robotsnowfall) |
| 2024-07-05 18:12:15 +0200 | robotsnowfall | (~robotsnow@user/robotsnowfall) (Quit: ZNC 1.9.1 - https://znc.in) |
| 2024-07-05 18:10:12 +0200 | mikess | (~mikess@user/mikess) |
| 2024-07-05 18:08:16 +0200 | noumenon | (~noumenon@2a01:799:cd8:e700:aa7e:eaff:fede:ff94) (Quit: Leaving) |
| 2024-07-05 18:06:54 +0200 | robotsnowfall | (~robotsnow@user/robotsnowfall) |
| 2024-07-05 18:05:19 +0200 | robotsnowfall | (~robotsnow@user/robotsnowfall) (Quit: ZNC 1.9.1 - https://znc.in) |
| 2024-07-05 18:05:14 +0200 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) |
| 2024-07-05 18:03:48 +0200 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Remote host closed the connection) |
| 2024-07-05 18:01:21 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2024-07-05 17:53:25 +0200 | robotsnowfall | (~robotsnow@user/robotsnowfall) |
| 2024-07-05 17:52:54 +0200 | robotsnowfall | (~robotsnow@user/robotsnowfall) (Quit: ZNC 1.9.1 - https://znc.in) |
| 2024-07-05 17:47:16 +0200 | chele | (~chele@user/chele) (Remote host closed the connection) |
| 2024-07-05 17:43:50 +0200 | danse-nr3 | (~danse-nr3@151.47.148.201) |
| 2024-07-05 17:43:34 +0200 | danse-nr3 | (~danse-nr3@151.47.162.188) (Read error: Connection reset by peer) |
| 2024-07-05 17:38:48 +0200 | incertia | (~incertia@209.122.137.252) |
| 2024-07-05 17:36:04 +0200 | robotsnowfall | (~robotsnow@user/robotsnowfall) |
| 2024-07-05 17:35:28 +0200 | robotsnowfall | (~robotsnow@user/robotsnowfall) (Client Quit) |
| 2024-07-05 17:35:02 +0200 | myxos | (~myxos@syn-065-028-251-121.res.spectrum.com) |
| 2024-07-05 17:34:46 +0200 | robotsnowfall | (~robotsnow@user/robotsnowfall) |
| 2024-07-05 17:34:23 +0200 | robotsnowfall | (~robotsnow@user/robotsnowfall) (Quit: ZNC 1.9.0 - https://znc.in) |
| 2024-07-05 17:34:20 +0200 | myxos | (~myxos@syn-065-028-251-121.res.spectrum.com) (Remote host closed the connection) |
| 2024-07-05 17:24:19 +0200 | soverysour | (~soverysou@user/soverysour) |
| 2024-07-05 17:24:19 +0200 | soverysour | (~soverysou@81.196.150.219) (Changing host) |
| 2024-07-05 17:24:18 +0200 | soverysour | (~soverysou@81.196.150.219) |
| 2024-07-05 17:22:37 +0200 | Joao[3] | (~Joao003@190.108.99.178) (Quit: Bye!) |
| 2024-07-05 17:21:51 +0200 | danse-nr3 | (~danse-nr3@151.47.162.188) |
| 2024-07-05 17:21:32 +0200 | soverysour | (~soverysou@user/soverysour) (Ping timeout: 268 seconds) |
| 2024-07-05 17:21:27 +0200 | danse-nr3 | (~danse-nr3@151.47.162.188) (Remote host closed the connection) |
| 2024-07-05 17:21:25 +0200 | Sgeo | (~Sgeo@user/sgeo) |
| 2024-07-05 17:20:00 +0200 | ubert1 | ubert |