2025/02/12

Newest at the top

2025-02-12 02:03:15 +0100califax_(~califax@user/califx) califx
2025-02-12 02:02:51 +0100acidjnk_new3(~acidjnk@p200300d6e7283f949088022741b454a0.dip0.t-ipconnect.de) (Ping timeout: 268 seconds)
2025-02-12 01:56:36 +0100zungi(~tory@user/andrewchawk) andrewchawk
2025-02-12 01:54:50 +0100merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 268 seconds)
2025-02-12 01:49:44 +0100merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-02-12 01:48:45 +0100attk(~attk@bras-base-toroon4524w-grc-50-70-31-30-224.dsl.bell.ca) (Remote host closed the connection)
2025-02-12 01:48:37 +0100 <Leary> kaol: If your ghc is recent enough, you have "multi-repl"; you can list multiple components or just do `cabal repl all`. For older GHC and ghciwatch, which don't support it, there's a nice way to write your cabal file such that you have a `dev` component that effectively combines the others without interfering with them: https://gist.github.com/LSLeary/6551f1dc3e25fe0d0d629b4ddb385359
2025-02-12 01:45:02 +0100szkl(uid110435@id-110435.uxbridge.irccloud.com) (Quit: Connection closed for inactivity)
2025-02-12 01:39:17 +0100alfiee(~alfiee@user/alfiee) (Ping timeout: 252 seconds)
2025-02-12 01:38:13 +0100merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 248 seconds)
2025-02-12 01:34:52 +0100alfiee(~alfiee@user/alfiee) alfiee
2025-02-12 01:31:42 +0100merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-02-12 01:25:32 +0100euouae(~euouae@user/euouae) ()
2025-02-12 01:25:06 +0100xff0x(~xff0x@2405:6580:b080:900:36c:449b:42ad:5dc6) (Ping timeout: 252 seconds)
2025-02-12 01:21:46 +0100Googulator(~Googulato@2a01-036d-0106-4074-758c-12a1-cbb4-05eb.pool6.digikabel.hu)
2025-02-12 01:21:29 +0100Googulator(~Googulato@2a01-036d-0106-4074-758c-12a1-cbb4-05eb.pool6.digikabel.hu) (Quit: Client closed)
2025-02-12 01:20:54 +0100merijn(~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 +0100merijn(~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 +0100dtman34(~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 +0100Sgeo(~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 +0100peterbecich(~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 ...`