2025/12/03

Newest at the top

2025-12-03 17:31:22 +0100 <tomsmeding> I can force GHC to do what I want by making the "inner function" NOINLINE (at which point the (inlined) "outer function" does the proper sharing), but that feels like a hack
2025-12-03 17:31:20 +0100 <Lycurgus> wo TH or nuthin i presume
2025-12-03 17:30:50 +0100 <tomsmeding> I have some data that I can already compute based on only the first argument that I would like to share over multiple calls that have the same first argument, and GHC isn't doing it
2025-12-03 17:30:19 +0100 <tomsmeding> can I override GHC's arity analysis to force a particular function to have lower arity than GHC would otherwise infer?
2025-12-03 17:28:55 +0100gawen(~gawen@user/gawen) (Quit: cya)
2025-12-03 17:25:15 +0100acidjnk(~acidjnk@p200300d6e71719231986af8ebf40e0fc.dip0.t-ipconnect.de) acidjnk
2025-12-03 17:17:58 +0100Lycurgus(~juan@user/Lycurgus) Lycurgus
2025-12-03 17:16:21 +0100trickard_(~trickard@cpe-85-98-47-163.wireline.com.au)
2025-12-03 17:06:01 +0100 <tomsmeding> (that data structure is Data.Set)
2025-12-03 17:05:47 +0100Googulator88(~Googulato@2a01-036d-0106-479c-d9ec-010d-f188-ffcb.pool6.digikabel.hu) (Quit: Client closed)
2025-12-03 17:05:45 +0100Googulator56(~Googulato@2a01-036d-0106-479c-d9ec-010d-f188-ffcb.pool6.digikabel.hu)
2025-12-03 17:05:43 +0100divlamir(~divlamir@user/divlamir) divlamir
2025-12-03 17:04:56 +0100 <tomsmeding> but the fact that you're asking about a list suggests you have no such ordering :)
2025-12-03 17:04:43 +0100trickard(~trickard@cpe-85-98-47-163.wireline.com.au) (Ping timeout: 255 seconds)
2025-12-03 17:04:39 +0100 <tomsmeding> __monty__: if the values have a well-defined ordering, a binary tree will give you O(log(n)) insertion instead of O(n)
2025-12-03 17:02:51 +0100tromp(~textual@2001:1c00:3487:1b00:a4ed:9e46:fd5d:6b4e)
2025-12-03 17:02:28 +0100divlamir(~divlamir@user/divlamir) (Ping timeout: 255 seconds)
2025-12-03 16:58:18 +0100acidjnk(~acidjnk@p200300d6e71719231986af8ebf40e0fc.dip0.t-ipconnect.de) (Ping timeout: 244 seconds)
2025-12-03 16:56:08 +0100pavonia(~user@user/siracusa) (Quit: Bye!)
2025-12-03 16:56:04 +0100merijn(~merijn@77.242.116.146) merijn
2025-12-03 16:55:13 +0100divlamir(~divlamir@user/divlamir) divlamir
2025-12-03 16:52:28 +0100Jackneill(~Jackneill@178-164-177-218.pool.digikabel.hu) Jackneill
2025-12-03 16:52:21 +0100 <__monty__> In my case the extra structure isn't necessary.
2025-12-03 16:52:16 +0100Jackneill(~Jackneill@178-164-177-218.pool.digikabel.hu) (Read error: Connection reset by peer)
2025-12-03 16:51:37 +0100 <Leary> __monty__: In that case, why flat? It really sounds like you want a heap or a set.
2025-12-03 16:50:41 +0100 <lambdabot> Foldable t => t a -> [a]
2025-12-03 16:50:38 +0100 <kuribas`> :t toList
2025-12-03 16:50:30 +0100 <kuribas`> __monty__: folds are isomorphic to a list
2025-12-03 16:50:26 +0100 <__monty__> I'm open to suggestions for a data structure for the specific case of pushing a value into the flat structure from the front and stopping when the value being pushed is smaller than the next. Think of a row of marbles, the first marble smaller than the one pushing against it falls out.
2025-12-03 16:49:57 +0100merijn(~merijn@77.242.116.146) (Ping timeout: 250 seconds)
2025-12-03 16:49:33 +0100 <Leary> Well, if you want to drop any elements. Maybe `Traversable` is enough if you don't.
2025-12-03 16:48:12 +0100 <Leary> `Witherable`, probably.
2025-12-03 16:46:53 +0100 <__monty__> I wasn't really asking about lists though. More like anything Foldable or Somethingable if folds are not a powerful enough concept to capture the behavior.
2025-12-03 16:45:34 +0100 <kuribas`> __monty__: tbf if you really care about performance, you shouldn't use linked lists.
2025-12-03 16:44:33 +0100lambda_gibbon(~lambda_gi@208.83.175.39)
2025-12-03 16:44:30 +0100 <kuribas`> ah no, it's added
2025-12-03 16:41:18 +0100 <__monty__> Oh, it's not.
2025-12-03 16:41:05 +0100 <__monty__> Probably because it's partial?
2025-12-03 16:40:02 +0100 <kuribas`> removed apparently...
2025-12-03 16:39:54 +0100tromp(~textual@2001:1c00:3487:1b00:a4ed:9e46:fd5d:6b4e) (Quit: My iMac has gone to sleep. ZZZzzz…)
2025-12-03 16:38:06 +0100 <kuribas`> https://hackage.haskell.org/package/base-4.21.0.0/docs/Data-List.html#v:tails1
2025-12-03 16:35:54 +0100 <lambdabot> Suggested fix:
2025-12-03 16:35:54 +0100 <lambdabot> Variable not in scope: tails1
2025-12-03 16:35:54 +0100 <lambdabot> error: [GHC-88464]
2025-12-03 16:35:51 +0100 <kuribas`> :t tails1
2025-12-03 16:33:59 +0100Googulator40(~Googulato@2a01-036d-0106-479c-d9ec-010d-f188-ffcb.pool6.digikabel.hu) (Ping timeout: 250 seconds)
2025-12-03 16:33:02 +0100merijn(~merijn@77.242.116.146) merijn
2025-12-03 16:32:44 +0100 <__monty__> "Foldr the init of the tails" is not quite the elegance I was hoping for but it does make foldr more useful still.
2025-12-03 16:31:10 +0100 <__monty__> Yeah, that works.
2025-12-03 16:30:47 +0100Googulator88(~Googulato@2a01-036d-0106-479c-d9ec-010d-f188-ffcb.pool6.digikabel.hu)