Newest at the top
| 2025-10-14 14:00:51 +0200 | Zemy_ | (~Zemy@2600:100c:b035:5997:3087:68ff:feb8:f43e) (Read error: Connection reset by peer) |
| 2025-10-14 14:00:02 +0200 | Zemy | (~Zemy@syn-076-184-041-021.res.spectrum.com) |
| 2025-10-14 13:59:35 +0200 | Zemy | (~Zemy@syn-076-184-041-021.res.spectrum.com) (Read error: Connection reset by peer) |
| 2025-10-14 13:59:35 +0200 | Zemy_ | (~Zemy@2600:100c:b035:5997:3087:68ff:feb8:f43e) |
| 2025-10-14 13:56:21 +0200 | <lortabac> | you can still make an operator with that behavior |
| 2025-10-14 13:55:39 +0200 | <lortabac> | it's useful but it doesn't make sense as a canonical instance |
| 2025-10-14 13:54:39 +0200 | <jackdk> | __monty__: People who want it will still be able to get it via `Map k (First v)` (`First` from `Data.Semigroup`) |
| 2025-10-14 13:53:33 +0200 | chromoblob | (~chromoblo@user/chromob1ot1c) chromoblob\0 |
| 2025-10-14 13:52:37 +0200 | <__monty__> | It's a useful behavior IMO, some languages have an operator for that kind of merging. |
| 2025-10-14 13:50:25 +0200 | <lortabac> | indeed your proposal makes more sense |
| 2025-10-14 13:49:28 +0200 | <jackdk> | lortabac: I consider it a footgun because it often does almost what you want: merge two maps together. But when keys clash it keeps the value in the left map, which is often surprising |
| 2025-10-14 13:49:15 +0200 | chromoblob | (~chromoblo@user/chromob1ot1c) (Ping timeout: 252 seconds) |
| 2025-10-14 13:48:56 +0200 | Square | (~Square4@user/square) Square |
| 2025-10-14 13:48:47 +0200 | weary-traveler | (~user@user/user363627) user363627 |
| 2025-10-14 13:48:28 +0200 | <lortabac> | jackdk: thanks, I didn't even know that instance existed |
| 2025-10-14 13:47:33 +0200 | <haskellbridge> | <Morj> dminuoso It makes more sense to use rust if you're coming from c++. I don't think it's a good choice instead of haskell in most cases. I write rust at work nowadays: the high-perf libraries are great, the application around it could be improved a lot with a smart runtime and a gc |
| 2025-10-14 13:47:31 +0200 | <jackdk> | lortabac: I consider `instance Ord k => Monoid (Map k)` to be a massive footgun, and think `instance (Ord k, Semigroup v) => Monoid (Map k v)` to be a better canonical instance. |
| 2025-10-14 13:47:16 +0200 | trickard_ | (~trickard@cpe-54-98-47-163.wireline.com.au) |
| 2025-10-14 13:47:02 +0200 | trickard | (~trickard@cpe-54-98-47-163.wireline.com.au) (Read error: Connection reset by peer) |
| 2025-10-14 13:46:41 +0200 | <lortabac> | jackdk: what is "the most cursed monoid instance"? |
| 2025-10-14 13:46:07 +0200 | <haskellbridge> | <Morj> lortabac oh thanks, I remember there was something, but couldn't recall. This is the one I thought about |
| 2025-10-14 13:44:50 +0200 | chromoblob | (~chromoblo@user/chromob1ot1c) chromoblob\0 |
| 2025-10-14 13:44:01 +0200 | chromoblob | (~chromoblo@user/chromob1ot1c) (Ping timeout: 246 seconds) |
| 2025-10-14 13:43:40 +0200 | <jackdk> | merijn: Also, we now have RequiredTypeArguments which makes it clearer when one is expected to pass an explicit type (as opposed to using haddocks or Proxy arguments) |
| 2025-10-14 13:43:03 +0200 | <jackdk> | merijn: Now that we have the machinery to deprecate instances, we could restart the crusade to fix the most cursed monoid instance |
| 2025-10-14 13:36:25 +0200 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) Lord_of_Life |
| 2025-10-14 13:35:52 +0200 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) (Ping timeout: 260 seconds) |
| 2025-10-14 13:31:33 +0200 | chele | (~chele@user/chele) chele |
| 2025-10-14 13:28:00 +0200 | peutri | (~peutri@bobo.desast.re) peutri |
| 2025-10-14 13:27:12 +0200 | pavonia | (~user@user/siracusa) (Read error: Connection reset by peer) |
| 2025-10-14 13:23:25 +0200 | xff0x | (~xff0x@2405:6580:b080:900:c19d:50a:4f2f:38d7) |
| 2025-10-14 13:20:49 +0200 | <dminuoso> | Sure, but then you wouldn't need to borrow references. |
| 2025-10-14 13:20:33 +0200 | <merijn> | dminuoso: I mean, you *can* just do reference counting in Rust afaik |
| 2025-10-14 13:20:15 +0200 | <merijn> | So I've never had a real use case to use Rust |
| 2025-10-14 13:20:14 +0200 | <dminuoso> | merijn: Maybe I'm just biased a bit *because* I have learned to work with C++ - in comparison Rust feels a lot more effort to avoid reference counting. |
| 2025-10-14 13:20:01 +0200 | <merijn> | And 90-95% of code just does not require anything like that |
| 2025-10-14 13:19:48 +0200 | <merijn> | If you're fine with GC and less memory control, you're better off just writing Haskell |
| 2025-10-14 13:19:33 +0200 | <merijn> | dminuoso: If you |
| 2025-10-14 13:19:29 +0200 | <merijn> | dminuoso: Rust seems great IFF I couldn't afford a garbage collector/less explicit memory control |
| 2025-10-14 13:19:04 +0200 | <merijn> | dminuoso: It sounds like you just don't have the problems Rust solves |
| 2025-10-14 13:18:28 +0200 | peutri_ | (~peutri@bobo.desast.re) (Ping timeout: 246 seconds) |
| 2025-10-14 13:17:30 +0200 | <dminuoso> | But maybe I haven't spent enough time with Rust yet, and you need a state of enlightenment before you can see it shine. |
| 2025-10-14 13:17:07 +0200 | <lambdabot> | 6 |
| 2025-10-14 13:17:06 +0200 | <lortabac> | > ala Sum foldMap [1,2,3] |
| 2025-10-14 13:17:01 +0200 | <lortabac> | Morj: there is 'ala', which is in lens (and other packages too) |
| 2025-10-14 13:16:37 +0200 | <dminuoso> | Even something mundane as writing a graph library is hell. |
| 2025-10-14 13:16:21 +0200 | <dminuoso> | Every time I dabbled with it, it felt more like most rust idioms exist to please the borrow checker, not because it leads to good semantics that you can reason about. |
| 2025-10-14 13:13:14 +0200 | <dminuoso> | Morj: Every time I stare at rust Im a bit confused how people willingly drift towards it. |
| 2025-10-14 13:12:57 +0200 | Zemy_ | (~Zemy@2600:100c:b035:5997:18fe:25ff:fe03:e2c) (Ping timeout: 252 seconds) |
| 2025-10-14 13:10:25 +0200 | MelodyOwO | (~MelodyOwO@user/MelodyOwO) MelodyOwO |