Newest at the top
| 2025-02-12 01:13:46 +0100 | <EvanR> | the cases for which it was invented, it really shines there |
| 2025-02-12 01:12:56 +0100 | <EvanR> | if it just didn't have type classes |
| 2025-02-12 01:12:47 +0100 | <EvanR> | haskell would be much more of a pain in the ass without it though |
| 2025-02-12 01:12:30 +0100 | <dminuoso> | typeclasses certainly are not the reason Im using Haskell. |
| 2025-02-12 01:12:29 +0100 | dtman34 | (~dtman34@2601:447:d000:1f5e:74c2:4ec:de8d:13d3) dtman34 |
| 2025-02-12 01:12:01 +0100 | <EvanR> | it's not a good thing to base the entire type class system, or break the whole system over |
| 2025-02-12 01:11:49 +0100 | <dminuoso> | Since you are forced to do one of them, authors will just do - and they dont agree. |
| 2025-02-12 01:11:46 +0100 | <EvanR> | Show is stupid for other reasons |
| 2025-02-12 01:11:37 +0100 | Sgeo | (~Sgeo@user/sgeo) Sgeo |
| 2025-02-12 01:11:33 +0100 | <dminuoso> | It's a matter of not having the choice. |
| 2025-02-12 01:11:32 +0100 | <EvanR> | that's like every other language, they never got to the point of having solid abstractions because they felt it was necessary to shoehorn stuff and hammer a screw with it |
| 2025-02-12 01:11:28 +0100 | <dminuoso> | When you have only a single typeclass for "turn this thing into human text" that widely exists, but there's this large mismatch between "produce some nice legible string" and "produce valid haskell expressions"... |
| 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 |