Newest at the top
| 2025-11-24 16:24:53 +0100 | <monochrom> | "But this is how groupBy should really have ended: Foldable f => (r :: a -> a -> Bool) -> (proof that r is really an equivalence relation) -> f a -> [NonEmpty a]" >:) |
| 2025-11-24 16:24:05 +0100 | <monochrom> | "How groupBy Should Have Ended" |
| 2025-11-24 16:21:57 +0100 | fp | (~Thunderbi@2001:708:20:1406::1370) (Quit: fp) |
| 2025-11-24 16:20:56 +0100 | <monochrom> | Since the input is any Foldable, you can still give it a normal list. |
| 2025-11-24 16:20:44 +0100 | <kuribas> | right :) |
| 2025-11-24 16:20:21 +0100 | <monochrom> | Data.List.Nonempty exports a groupBy :: Foldable f => (a -> a -> Bool) -> f a -> [NonEmpty a] |
| 2025-11-24 16:13:48 +0100 | Frostillicus | (~Frostilli@pool-71-174-119-69.bstnma.fios.verizon.net) |
| 2025-11-24 16:11:38 +0100 | <kuribas> | Maybe a bit less heavy on dependencies. |
| 2025-11-24 16:11:24 +0100 | <kuribas> | ah, that's basically NonEmpty... |
| 2025-11-24 16:10:36 +0100 | <kuribas> | groupBy should have been forall a. (a -> a -> a) -> [a] -> [(a, [a])] |
| 2025-11-24 16:10:31 +0100 | fp | (~Thunderbi@2001:708:20:1406::1370) fp |
| 2025-11-24 16:09:34 +0100 | gustrb | (~gustrb@user/gustrb) gustrb |
| 2025-11-24 16:08:55 +0100 | Frostillicus | (~Frostilli@pool-71-174-119-69.bstnma.fios.verizon.net) (Ping timeout: 255 seconds) |
| 2025-11-24 16:08:44 +0100 | gustrb | (~gustrb@user/gustrb) (Read error: Connection reset by peer) |
| 2025-11-24 16:06:14 +0100 | <geekosaur> | and is so core that pretty much everything in both core and contrib would have to be modified |
| 2025-11-24 16:05:36 +0100 | <geekosaur> | well, there's also that the case where I personally run into this "correctly" should be solved in xmonad core… by breaking the API of a central structure that's been fixed since at least 0.2 |
| 2025-11-24 16:04:50 +0100 | CiaoSen | (~Jura@2a02:8071:64e1:da0:5a47:caff:fe78:33db) (Ping timeout: 256 seconds) |
| 2025-11-24 16:03:46 +0100 | <kuribas> | groupBy in idris uses List1 |
| 2025-11-24 16:03:34 +0100 | <haskellbridge> | <Morj> I find that NonEmpty is fine when you're inside the ecosystem that's more abstract over it's data types. A lot of functions take a list instead of a traversable. I find the pain slightly smaller with mono-traversable and everything that uses it |
| 2025-11-24 16:02:44 +0100 | fp | (~Thunderbi@130.233.70.108) (Read error: Connection reset by peer) |
| 2025-11-24 16:02:35 +0100 | <Leary> | It's not a solution to every non-empty list problem, but it /is/ a solution to giving `groupBy` a good signature. |
| 2025-11-24 16:02:22 +0100 | fp | (~Thunderbi@130.233.70.108) fp |
| 2025-11-24 16:02:08 +0100 | <Leary> | `x:|xs` has no more constructors/expense than `x:xs`. |
| 2025-11-24 16:01:55 +0100 | <geekosaur> | imo NonEmpty isn't a solution, it's an ugly hack around Haskell missing that aspect of dependent types |
| 2025-11-24 16:01:04 +0100 | <geekosaur> | well, yes, if you can use NonEmoty then it's not a problem. but I find NonEmpty somewhat annoying and sometimes a bit expensive since it's adding constructors that are pointless at runtime |
| 2025-11-24 16:01:01 +0100 | <haskellbridge> | <Morj> 2. You can use a partial function like "fromJust . uncons" |
| 2025-11-24 16:00:23 +0100 | <geekosaur> | (this is why uni-patterns is a separate warning) |
| 2025-11-24 16:00:19 +0100 | <Leary> | kuribas: Use `Data.List.NonEmpty.groupBy`. |
| 2025-11-24 16:00:04 +0100 | weary-traveler | (~user@user/user363627) user363627 |
| 2025-11-24 15:59:57 +0100 | <kuribas> | well, lambdacase |
| 2025-11-24 15:59:55 +0100 | <haskellbridge> | <Morj> 1. Refactor all your code to put NonEmpty there ;-) |
| 2025-11-24 15:59:48 +0100 | weary-traveler | (~user@user/user363627) (Quit: Konversation terminated!) |
| 2025-11-24 15:59:48 +0100 | <kuribas> | It's nice to have, but not here. |
| 2025-11-24 15:59:45 +0100 | <geekosaur> | since there's no way to add the other case even if it mattered |
| 2025-11-24 15:59:34 +0100 | <geekosaur> | best you can do is -Wno-incomplete-uni-patterns, I think |
| 2025-11-24 15:55:49 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Quit: = "") |
| 2025-11-24 15:54:34 +0100 | <kuribas> | well, warning. |
| 2025-11-24 15:54:28 +0100 | <kuribas> | Empty list is impossible here. |
| 2025-11-24 15:54:16 +0100 | <kuribas> | If I do map (\(x:xs) -> ...) $ groupBy .., how do I avoid the exhaustive error? |
| 2025-11-24 15:53:39 +0100 | <kuribas> | ok, it works now. |
| 2025-11-24 15:52:25 +0100 | fp | (~Thunderbi@wireless-86-50-141-141.open.aalto.fi) (Remote host closed the connection) |
| 2025-11-24 15:49:48 +0100 | kuribas | (~user@ip-188-118-57-242.reverse.destiny.be) kuribas |
| 2025-11-24 15:49:29 +0100 | kuribas | (~user@ip-188-118-57-242.reverse.destiny.be) (Remote host closed the connection) |
| 2025-11-24 15:49:11 +0100 | ttybitnik | (~ttybitnik@user/wolper) (Remote host closed the connection) |
| 2025-11-24 15:48:08 +0100 | <kuribas> | hmm, I can try that |
| 2025-11-24 15:47:52 +0100 | <haskellbridge> | <Morj> Some time ago stack also added ghcup integration instead of using its own packages, but I'm not sure how it works |
| 2025-11-24 15:47:21 +0100 | <haskellbridge> | <Morj> I prefer to always set system-ghc: true in stack to prevent that |
| 2025-11-24 15:46:38 +0100 | <kuribas> | Ah, I think stack is fixing this ghc... |
| 2025-11-24 15:46:16 +0100 | <haskellbridge> | <Morj> Sorry, I'm not familiar with emacs, so I'm doing first-line help advice here |
| 2025-11-24 15:46:12 +0100 | <kuribas> | hmm, there is a .stack-work with ghc-8.10.7 |