Newest at the top
| 2025-02-12 01:39:17 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 252 seconds) |
| 2025-02-12 01:38:13 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 248 seconds) |
| 2025-02-12 01:34:52 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-02-12 01:31:42 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-02-12 01:25:32 +0100 | euouae | (~euouae@user/euouae) () |
| 2025-02-12 01:25:06 +0100 | xff0x | (~xff0x@2405:6580:b080:900:36c:449b:42ad:5dc6) (Ping timeout: 252 seconds) |
| 2025-02-12 01:21:46 +0100 | Googulator | (~Googulato@2a01-036d-0106-4074-758c-12a1-cbb4-05eb.pool6.digikabel.hu) |
| 2025-02-12 01:21:29 +0100 | Googulator | (~Googulato@2a01-036d-0106-4074-758c-12a1-cbb4-05eb.pool6.digikabel.hu) (Quit: Client closed) |
| 2025-02-12 01:20:54 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 260 seconds) |
| 2025-02-12 01:17:58 +0100 | <EvanR> | an extreme example of manually passing a dictionary, but it's pretty doable for 1 string |
| 2025-02-12 01:17:13 +0100 | <EvanR> | just pass the string form (lazily perhaps, if you might not use it) |
| 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) |