Newest at the top
| 2025-12-03 17:37:06 +0100 | <tomsmeding> | (it's a 2x improvement when called many times, at the cost of a 10% slowdown when called once) |
| 2025-12-03 17:36:45 +0100 | <tomsmeding> | but I'll just have to live with that I suppose :) |
| 2025-12-03 17:36:33 +0100 | <tomsmeding> | the downside is that that makes performance slightly worse if the function is only called once |
| 2025-12-03 17:35:53 +0100 | <Leary> | `NOINLINE` it is, then. |
| 2025-12-03 17:35:50 +0100 | haritz | (~hrtz@user/haritz) haritz |
| 2025-12-03 17:35:50 +0100 | haritz | (~hrtz@2a01:4b00:bc2e:7000:d5af:a266:ca31:5ef8) (Changing host) |
| 2025-12-03 17:35:50 +0100 | haritz | (~hrtz@2a01:4b00:bc2e:7000:d5af:a266:ca31:5ef8) |
| 2025-12-03 17:35:27 +0100 | <tomsmeding> | Leary: doesn't seem to; they were already in a separate lambda (within a 'let' that defines the shared binding), but adding a ! doesn't seem to help |
| 2025-12-03 17:34:58 +0100 | <Lycurgus> | *could |
| 2025-12-03 17:34:56 +0100 | aljazmc | (~aljazmc@user/aljazmc) aljazmc |
| 2025-12-03 17:34:35 +0100 | <Lycurgus> | *query |
| 2025-12-03 17:34:29 +0100 | aljazmc | (~aljazmc@user/aljazmc) (Remote host closed the connection) |
| 2025-12-03 17:34:05 +0100 | <Leary> | tomsmeding: Does it work if you push the latter args into lambdas and bang the shared binding? |
| 2025-12-03 17:33:37 +0100 | <Lycurgus> | i couild expand as a very rude name of this category of quety has occured to me but being a real person i know better |
| 2025-12-03 17:33:28 +0100 | gawen | (~gawen@user/gawen) gawen |
| 2025-12-03 17:32:55 +0100 | <tomsmeding> | well, presumably something is relevant here, yes |
| 2025-12-03 17:32:45 +0100 | <Lycurgus> | nor "nuthin"? |
| 2025-12-03 17:32:33 +0100 | <tomsmeding> | (I don't see how TH is relevant here) |
| 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 +0100 | gawen | (~gawen@user/gawen) (Quit: cya) |
| 2025-12-03 17:25:15 +0100 | acidjnk | (~acidjnk@p200300d6e71719231986af8ebf40e0fc.dip0.t-ipconnect.de) acidjnk |
| 2025-12-03 17:17:58 +0100 | Lycurgus | (~juan@user/Lycurgus) Lycurgus |
| 2025-12-03 17:16:21 +0100 | trickard_ | (~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 +0100 | Googulator88 | (~Googulato@2a01-036d-0106-479c-d9ec-010d-f188-ffcb.pool6.digikabel.hu) (Quit: Client closed) |
| 2025-12-03 17:05:45 +0100 | Googulator56 | (~Googulato@2a01-036d-0106-479c-d9ec-010d-f188-ffcb.pool6.digikabel.hu) |
| 2025-12-03 17:05:43 +0100 | divlamir | (~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 +0100 | trickard | (~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 +0100 | tromp | (~textual@2001:1c00:3487:1b00:a4ed:9e46:fd5d:6b4e) |
| 2025-12-03 17:02:28 +0100 | divlamir | (~divlamir@user/divlamir) (Ping timeout: 255 seconds) |
| 2025-12-03 16:58:18 +0100 | acidjnk | (~acidjnk@p200300d6e71719231986af8ebf40e0fc.dip0.t-ipconnect.de) (Ping timeout: 244 seconds) |
| 2025-12-03 16:56:08 +0100 | pavonia | (~user@user/siracusa) (Quit: Bye!) |
| 2025-12-03 16:56:04 +0100 | merijn | (~merijn@77.242.116.146) merijn |
| 2025-12-03 16:55:13 +0100 | divlamir | (~divlamir@user/divlamir) divlamir |
| 2025-12-03 16:52:28 +0100 | Jackneill | (~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 +0100 | Jackneill | (~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 +0100 | merijn | (~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. |