Newest at the top
| 2025-01-31 17:38:14 +0100 | EvanR | (~EvanR@user/evanr) EvanR |
| 2025-01-31 17:36:52 +0100 | EvanR | (~EvanR@user/evanr) (Quit: Leaving) |
| 2025-01-31 17:35:41 +0100 | ash3en | (~Thunderbi@146.70.124.222) ash3en |
| 2025-01-31 17:35:24 +0100 | ash3en | (~Thunderbi@2a03:7846:b6eb:101:93ac:a90a:da67:f207) (Ping timeout: 260 seconds) |
| 2025-01-31 17:34:03 +0100 | Square | (~Square@user/square) Square |
| 2025-01-31 17:32:28 +0100 | zmt00 | (~zmt00@user/zmt00) (Ping timeout: 272 seconds) |
| 2025-01-31 17:31:46 +0100 | ubert | (~Thunderbi@2a02:8109:ab8a:5a00:a8f9:39f9:ef80:a859) (Ping timeout: 244 seconds) |
| 2025-01-31 17:30:26 +0100 | Digit | (~user@user/digit) Digit |
| 2025-01-31 17:27:26 +0100 | zmt00 | (~zmt00@user/zmt00) zmt00 |
| 2025-01-31 17:23:30 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 244 seconds) |
| 2025-01-31 17:22:06 +0100 | RMSBach | (~guygastin@137.184.131.156) (Ping timeout: 252 seconds) |
| 2025-01-31 17:19:28 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-01-31 17:15:15 +0100 | Guest87 | (~Guest92@14.194.140.178) |
| 2025-01-31 17:10:46 +0100 | <ski> | (ah .. `xInt :: ((x :: Int) => o) -> o') |
| 2025-01-31 17:10:15 +0100 | <ski> | (or `xInt :: ((x :: Int) -> o) -> o', skipping `Dict_XInt') |
| 2025-01-31 17:09:41 +0100 | <ski> | hm, looks like `data Dict_XInt = (x :: Int) => WrapXInt' works, and i suppose one could then try `class XInt where xInt :: Dict_XInt' .. hmmm |
| 2025-01-31 17:09:10 +0100 | Guest37 | (~Guest62@c-73-217-79-154.hsd1.co.comcast.net) (Ping timeout: 240 seconds) |
| 2025-01-31 17:07:57 +0100 | <ski> | hm, i see |
| 2025-01-31 17:05:04 +0100 | <slack1256> | ski: Even with -XConstraintKinds we cannot use implicit parameters on instance heads... |
| 2025-01-31 17:03:49 +0100 | euleritian | (~euleritia@ip4d17fae8.dynamic.kabel-deutschland.de) |
| 2025-01-31 17:03:31 +0100 | euleritian | (~euleritia@dynamic-176-006-142-115.176.6.pool.telefonica.de) (Read error: Connection reset by peer) |
| 2025-01-31 17:03:20 +0100 | GoldsteinQ | (~goldstein@goldstein.rs) |
| 2025-01-31 17:00:39 +0100 | GoldsteinQ | (~goldstein@goldstein.rs) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2025-01-31 16:57:50 +0100 | <ski> | slack1256 : constraint synonyms ? |
| 2025-01-31 16:54:42 +0100 | acidjnk_new3 | (~acidjnk@p200300d6e7283f83edaedff6126e1841.dip0.t-ipconnect.de) (Ping timeout: 252 seconds) |
| 2025-01-31 16:53:05 +0100 | L29Ah | (~L29Ah@wikipedia/L29Ah) L29Ah |
| 2025-01-31 16:49:18 +0100 | L29Ah | (~L29Ah@wikipedia/L29Ah) () |
| 2025-01-31 16:46:28 +0100 | GoldsteinQ | (~goldstein@goldstein.rs) |
| 2025-01-31 16:46:20 +0100 | ystael | (~ystael@user/ystael) ystael |
| 2025-01-31 16:45:18 +0100 | vanishingideal | (~vanishing@user/vanishingideal) vanishingideal |
| 2025-01-31 16:44:24 +0100 | ystael_ | (~ystael@user/ystael) (Quit: Lost terminal) |
| 2025-01-31 16:43:05 +0100 | GoldsteinQ | (~goldstein@goldstein.rs) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2025-01-31 16:41:24 +0100 | hueso | (~root@user/hueso) hueso |
| 2025-01-31 16:39:15 +0100 | hueso | (~root@user/hueso) (Quit: No Ping reply in 180 seconds.) |
| 2025-01-31 16:37:08 +0100 | Guest37 | (~Guest62@c-73-217-79-154.hsd1.co.comcast.net) |
| 2025-01-31 16:36:57 +0100 | vektor | (~vektor@IP-149249154134.pools.medianet-world.de) |
| 2025-01-31 16:36:50 +0100 | <dminuoso> | Hard to imagine why there would be more than one. |
| 2025-01-31 16:36:37 +0100 | <dminuoso> | slack1256: Again, hard to say without knowing more about your code - but ideally there wouldnt be many places where you resolve effects. |
| 2025-01-31 16:36:30 +0100 | L29Ah | (~L29Ah@wikipedia/L29Ah) L29Ah |
| 2025-01-31 16:36:04 +0100 | <slack1256> | dminuoso: "Resolve them coherently" is the problem, I have to do it by hand instaed of using typeclasses. I have to duplicate the callers of those functions, the different constraints bubble up. If I could abstract over implicit parameters with classes I could delegate this to the compiler to choose the right calling convention. |
| 2025-01-31 16:34:08 +0100 | <dminuoso> | It's certainly not ideal, but no migration ever was. |
| 2025-01-31 16:33:46 +0100 | <dminuoso> | So some parts just use the effect, others use implicit params. |
| 2025-01-31 16:33:28 +0100 | <dminuoso> | slack1256: That said, Im not entirely sure you need any partial solution here. During migration you can also just have *both* some effect and an implicit parameter, just make sure you resolve them coherently until the implicit params are gone. |
| 2025-01-31 16:33:15 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 252 seconds) |
| 2025-01-31 16:30:13 +0100 | <geekosaur> | and they break reasoning about code |
| 2025-01-31 16:29:59 +0100 | <geekosaur> | I don't think I've ever seen a use for implicit params that waasn't better served some other way |
| 2025-01-31 16:29:44 +0100 | <geekosaur> | tbh if you're using an effect system, its state abstraction is an IORef (because effect systems are fancy ReaderT, more or less) and switching to that is the saner option than implicit params anyway |
| 2025-01-31 16:29:04 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-01-31 16:28:57 +0100 | <dminuoso> | slack1256: Its hard to tell without a bit more context, unsure whether the example is contrived or whether this is truly just about database connection strings |
| 2025-01-31 16:27:02 +0100 | <slack1256> | dminuoso: too much code already uses it on the codebase. We are in a middle of a sprint and other developers are making changes to their own modules. Changing them all in a big PR would cause a lot of conflicts when trying to merge. |