Newest at the top
| 2025-05-04 19:00:52 +0200 | ystael | (~ystael@user/ystael) ystael |
| 2025-05-04 18:59:31 +0200 | Guest70 | (~Guest80@82.153.135.43) (Client Quit) |
| 2025-05-04 18:58:47 +0200 | ttybitnik | (~ttybitnik@user/wolper) (Remote host closed the connection) |
| 2025-05-04 18:58:01 +0200 | Guest70 | (~Guest80@82.153.135.43) |
| 2025-05-04 18:57:29 +0200 | ljdarj | (~Thunderbi@user/ljdarj) (Ping timeout: 268 seconds) |
| 2025-05-04 18:56:03 +0200 | tzh | (~tzh@c-76-115-131-146.hsd1.or.comcast.net) |
| 2025-05-04 18:55:19 +0200 | Arpad | (~Arpad@2a02:ab88:38d:4700::b0d5) |
| 2025-05-04 18:46:44 +0200 | euphores | (~SASL_euph@user/euphores) euphores |
| 2025-05-04 18:43:44 +0200 | ChaiTRex | (~ChaiTRex@user/chaitrex) ChaiTRex |
| 2025-05-04 18:42:23 +0200 | __jmcantrell__ | (~weechat@user/jmcantrell) jmcantrell |
| 2025-05-04 18:42:19 +0200 | euleritian | (~euleritia@77.23.248.47) |
| 2025-05-04 18:42:12 +0200 | ChaiTRex | (~ChaiTRex@user/chaitrex) (Ping timeout: 264 seconds) |
| 2025-05-04 18:41:39 +0200 | euleritian | (~euleritia@77.23.248.47) (Read error: Connection reset by peer) |
| 2025-05-04 18:40:05 +0200 | euleritian | (~euleritia@77.23.248.47) |
| 2025-05-04 18:39:47 +0200 | euleritian | (~euleritia@dynamic-176-006-131-173.176.6.pool.telefonica.de) (Read error: Connection reset by peer) |
| 2025-05-04 18:38:33 +0200 | <EvanR> | I'm ok if Data.Map's implementation is packed with esoteric constants and jiggery pokery if it means more performance and I never have to mess with it xD |
| 2025-05-04 18:35:22 +0200 | euphores | (~SASL_euph@user/euphores) (Quit: Leaving.) |
| 2025-05-04 18:29:13 +0200 | <geekosaur> | and, uh, look at the implementation. they're usually pretty expensive. I mean, even a list zipper turns one list into two plus a lot of pushing and popping |
| 2025-05-04 18:27:58 +0200 | <Pozyomka> | Wow, and there's magical constants in the code too... |
| 2025-05-04 18:27:03 +0200 | <int-e> | that said, yes, zippers are heavy machinery in the sense that they tend to require a lot of code for non-trivial data structures |
| 2025-05-04 18:26:36 +0200 | <int-e> | and as far as I can tell, that was introduced just for the benefit of alterF |
| 2025-05-04 18:26:21 +0200 | <Pozyomka> | Wow, that's just... bonkers. |
| 2025-05-04 18:25:44 +0200 | <int-e> | it remembers a path in a bit mask |
| 2025-05-04 18:25:23 +0200 | <int-e> | Pozyomka: there's no zipper |
| 2025-05-04 18:20:50 +0200 | j1n37 | (~j1n37@user/j1n37) j1n37 |
| 2025-05-04 18:19:23 +0200 | <Pozyomka> | int-e: “pretty heavy machinery” -- Are zippers heavy machinery now? |
| 2025-05-04 18:18:42 +0200 | CiaoSen | (~Jura@2a02:8071:64e1:da0:5a47:caff:fe78:33db) (Ping timeout: 276 seconds) |
| 2025-05-04 18:16:34 +0200 | j1n37 | (~j1n37@user/j1n37) (Ping timeout: 244 seconds) |
| 2025-05-04 18:11:08 +0200 | <Pozyomka> | The lengths through which Haskell programmers go to avoid defining types to represent intermediate steps of the lookup process... “I'd rather write a higher-order function with a Functor constraint than define a zipper type!” |
| 2025-05-04 18:05:36 +0200 | alecs | (~alecs@61.pool85-58-154.dynamic.orange.es) alecs |
| 2025-05-04 17:58:50 +0200 | <int-e> | (Even for Data.Map, I believe the main thing it saves is repeated key comparisons. Which of course may be expensive, depending on the key type.) |
| 2025-05-04 17:56:32 +0200 | <lambdabot> | (Functor f, Ord k) => (Maybe a -> f (Maybe a)) -> k -> M.Map k a -> f (M.Map k a) |
| 2025-05-04 17:56:31 +0200 | <int-e> | :t Data.Map.alterF |
| 2025-05-04 17:56:09 +0200 | <lambdabot> | Perhaps you meant one of these: |
| 2025-05-04 17:56:09 +0200 | <lambdabot> | Not in scope: ‘Data.Map.adjustF’ |
| 2025-05-04 17:56:08 +0200 | <lambdabot> | error: |
| 2025-05-04 17:56:07 +0200 | <int-e> | :t Data.Map.adjustF |
| 2025-05-04 17:55:15 +0200 | <int-e> | The Data.Map version of this introduces some pretty heavy machinery to both find the altered element and remember the path to the corresponding leaf, and then reuses that path to speed up the update process. For Data.Sequence.Seq I think the potential savings over the obvious lookup and then fmap adjust aren't nearly as impressive. |
| 2025-05-04 17:50:53 +0200 | JuanDaugherty | (~juan@user/JuanDaugherty) JuanDaugherty |
| 2025-05-04 17:45:40 +0200 | sajenim | (~sajenim@user/sajenim) (Ping timeout: 252 seconds) |
| 2025-05-04 17:44:37 +0200 | lxsameer | (~lxsameer@Serene/lxsameer) lxsameer |
| 2025-05-04 17:44:23 +0200 | j1n37 | (~j1n37@user/j1n37) j1n37 |
| 2025-05-04 17:44:03 +0200 | <[exa]> | ok well probably not the case, the internal "single-lookup adjust" in the package doesn't seem to support passing the functors through |
| 2025-05-04 17:43:50 +0200 | j1n37 | (~j1n37@user/j1n37) (Ping timeout: 252 seconds) |
| 2025-05-04 17:39:08 +0200 | hiecaq | (~hiecaq@user/hiecaq) (Quit: ERC 5.6.0.30.1 (IRC client for GNU Emacs 30.0.92)) |
| 2025-05-04 17:30:01 +0200 | <[exa]> | Pozyomka: not really but maybe it would be redundant with other functions there? |
| 2025-05-04 17:28:00 +0200 | pavonia | (~user@user/siracusa) (Quit: Bye!) |
| 2025-05-04 17:16:27 +0200 | m1dnight | (~m1dnight@d8D861908.access.telenet.be) m1dnight |
| 2025-05-04 17:12:42 +0200 | CiaoSen | (~Jura@2a02:8071:64e1:da0:5a47:caff:fe78:33db) CiaoSen |
| 2025-05-04 17:11:34 +0200 | m1dnight | (~m1dnight@d8D861908.access.telenet.be) (Ping timeout: 252 seconds) |