Newest at the top
| 2025-02-12 01:10:58 +0100 | <EvanR> | if the solid abstraction isn't doing what you want, the answer is probably not to break the abstraction for everyone, just don't use this abstraction |
| 2025-02-12 01:10:49 +0100 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 260 seconds) |
| 2025-02-12 01:10:34 +0100 | <dminuoso> | I think its quite related. |
| 2025-02-12 01:10:30 +0100 | <EvanR> | anyway solid abstractions that are actually solid is great as long as you can do what you need to do with it |
| 2025-02-12 01:09:38 +0100 | <EvanR> | but Show type issues are a separate ergonomic issue from type class mechanisms I think |
| 2025-02-12 01:09:05 +0100 | <EvanR> | yeah I have dumb newtypes specifically to change the show instance |
| 2025-02-12 01:09:00 +0100 | <dminuoso> | So dunno, feels like incoherence is already upon us,. |
| 2025-02-12 01:08:43 +0100 | <dminuoso> | Or `newtype SortAfterShow ...` |
| 2025-02-12 01:08:33 +0100 | <dminuoso> | Say `newtype UppercaseShow ...` |
| 2025-02-12 01:08:26 +0100 | <dminuoso> | Or well, except for those versions that do silly things |
| 2025-02-12 01:08:17 +0100 | <dminuoso> | The one thing is just, that if you have `f :: forall a. Show a => ...` you know that f cant possibly use any newtype wrappers to swap out the Show instance because of parametricity. |
| 2025-02-12 01:06:51 +0100 | <EvanR> | and no one is surprised |
| 2025-02-12 01:06:31 +0100 | <EvanR> | just slapping the newtype constructor activates the special behavior |
| 2025-02-12 01:06:09 +0100 | <EvanR> | I know, newtypes are great |
| 2025-02-12 01:05:52 +0100 | <EvanR> | (when someone didn't expect this) |
| 2025-02-12 01:05:47 +0100 | <dminuoso> | EvanR: Yes, and this is not a problem with newtype either. |
| 2025-02-12 01:05:45 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 276 seconds) |
| 2025-02-12 01:05:37 +0100 | <EvanR> | code A sees instance B while code C sees instance D of the same typeclass on the same type |
| 2025-02-12 01:05:21 +0100 | ljdarj1 | ljdarj |
| 2025-02-12 01:05:21 +0100 | ljdarj | (~Thunderbi@user/ljdarj) (Ping timeout: 246 seconds) |
| 2025-02-12 01:05:15 +0100 | <dminuoso> | If we had a mechanism of dict application that just skipped the instance resolution, the big benefit would be not having to wrap through newtype just for force instance selection |
| 2025-02-12 01:04:57 +0100 | <EvanR> | just like using imperative programming everywhere where it wouldn't help 99% of the time |
| 2025-02-12 01:04:38 +0100 | <dminuoso> | I mean writing newtypes with custom instances, and then selecting those instances is not a problem either. |
| 2025-02-12 01:04:34 +0100 | <EvanR> | other languages have mechanisms for using explicit instances and there comes with it the additional cognitive overhead |
| 2025-02-12 01:04:08 +0100 | <dminuoso> | If we had the freedom to just say "Dont resolve, Ill decide here locally", much of the incoherence problems disappear. |
| 2025-02-12 01:03:49 +0100 | <dminuoso> | EvanR: Note, Im not talking about forcing automatic instance resolution. |
| 2025-02-12 01:03:19 +0100 | <EvanR> | code A sees instance B while code C sees instance D of the same typeclass on the same type |
| 2025-02-12 01:03:18 +0100 | <dminuoso> | EvanR: I've been using orphan instances a plenty lot without having any occurence of that. |
| 2025-02-12 01:03:05 +0100 | <ski> | well, avoiding needing to parameterize over nonlocal tyvars, at least |
| 2025-02-12 01:02:41 +0100 | <EvanR> | dminuoso, it's really nice not having to worry about incoherent instances |
| 2025-02-12 01:02:38 +0100 | <ski> | ah |
| 2025-02-12 01:02:35 +0100 | <dminuoso> | A module level type |
| 2025-02-12 01:02:24 +0100 | <ski> | benefit over what ? |
| 2025-02-12 01:02:11 +0100 | <ski> | mm |
| 2025-02-12 01:02:09 +0100 | <dminuoso> | At that point I'm not too sure what benefit you would gain. |
| 2025-02-12 01:01:57 +0100 | <ski> | perhaps it would be nice to have two variants, one requiring uniqueness, and the other not .. i dunno |
| 2025-02-12 01:01:55 +0100 | <dminuoso> | At least for `data` GHC would have to drag the type in interface files in case of inlining. |
| 2025-02-12 01:01:39 +0100 | ljdarj1 | (~Thunderbi@user/ljdarj) ljdarj |
| 2025-02-12 01:01:14 +0100 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) peterbecich |
| 2025-02-12 01:00:57 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-02-12 01:00:37 +0100 | <ski> | as long as the instance is given in the same scope as the data type, i think there'd be no issue with coherence |
| 2025-02-12 01:00:06 +0100 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 246 seconds) |
| 2025-02-12 00:59:56 +0100 | <dminuoso> | Oh, locally scoped instances yes. |
| 2025-02-12 00:59:36 +0100 | <ski> | occasionally, i'd like to be able to define types (possibly non-locally depending on tyvars in scope) in `where' and `let', as well as making instances for them there |
| 2025-02-12 00:59:03 +0100 | <dminuoso> | The discussions Ive seen over the years consistently bring up coherence issues, but they feel contrived. |
| 2025-02-12 00:58:25 +0100 | <ski> | mm |
| 2025-02-12 00:58:09 +0100 | <dminuoso> | ski: At times I do wish we had a mechanism to just swap out typeclass instances, or have some overlapping ones and then decide which ones I want. |
| 2025-02-12 00:56:31 +0100 | <dminuoso> | Oh well, I think I understand what the diagnostic is really trying to say |
| 2025-02-12 00:55:20 +0100 | <ski> | (assuming `data Showable = forall a. Show a => WrapShowable a', and `withShowable :: Showable -> (forall a. Show a => a -> o) -> o') |
| 2025-02-12 00:55:09 +0100 | <dminuoso> | But that has no associated forall either.. |