Newest at the top
| 2025-02-12 01:16:55 +0100 | <EvanR> | like most examples of trying to save or restore Show instances |
| 2025-02-12 01:16:42 +0100 | <EvanR> | the example of forall a . Show a => being inflexible, this would be much better just as "pass in a string instead of using a constraint" |
| 2025-02-12 01:16:18 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-02-12 01:15:28 +0100 | <EvanR> | I just ignore Show and wish that the interactive interpreter could just show anything without any code or deriving, and this one off feature |
| 2025-02-12 01:15:12 +0100 | <dminuoso> | Im not convinced calling those instances "bad" is sensible at this point. |
| 2025-02-12 01:15:04 +0100 | <ski> | yes. i see no reason to abandon that vision, still |
| 2025-02-12 01:14:43 +0100 | <dminuoso> | ski: That was the original intent some decades ago. The reality of hackage tells a different story. |
| 2025-02-12 01:14:32 +0100 | <EvanR> | and if there's a better tool we can invent that other tool |
| 2025-02-12 01:14:14 +0100 | <EvanR> | for other purposes it might not be the best tool |
| 2025-02-12 01:14:10 +0100 | <ski> | (`Show' and `Read' are not for custom formatting. the instances on different types are meant to play together (`instance Show a => Show (Maybe a)',&c.). this, imho means that if your instance doesn't use valid Haskell source code format (either data constructors, or exported abstract operations), your instance is bad) |
| 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. |