Newest at the top
| 2025-12-03 15:47:39 +0100 | Guest6657 | (~inline@cgn-195-14-221-120.nc.de) (Quit: Leaving) |
| 2025-12-03 15:45:27 +0100 | gawen | (~gawen@user/gawen) (Quit: cya) |
| 2025-12-03 15:40:33 +0100 | <sprout> | yah |
| 2025-12-03 15:40:24 +0100 | <tomsmeding> | then you just punt the problem to the implementation of that monad |
| 2025-12-03 15:39:45 +0100 | <sprout> | put it in a monad? I feel like parser combinators will often return the unprocessed tokens on an error, so you should be able to reuse the idiom |
| 2025-12-03 15:37:58 +0100 | Pozyomka | (~pyon@user/pyon) pyon |
| 2025-12-03 15:37:57 +0100 | <sprout> | hmyah |
| 2025-12-03 15:37:55 +0100 | akegalj | (~akegalj@141-138-27-206.dsl.iskon.hr) |
| 2025-12-03 15:37:53 +0100 | <__monty__> | sprout: Again, that leaves me with only part of the input, no? |
| 2025-12-03 15:37:48 +0100 | <tomsmeding> | sprout: scan doesn't give you access to the actual original tail |
| 2025-12-03 15:37:26 +0100 | <__monty__> | But that's not the "shortcutting" I'm looking for. I want to recurse up to a point and at that point return the tail unprocessed. The latter is just for efficiency rather than correctness. |
| 2025-12-03 15:37:20 +0100 | <sprout> | you can do a scan instead of a fold and lazily stop evaluating when you hit something |
| 2025-12-03 15:36:23 +0100 | <tomsmeding> | yes I think so |
| 2025-12-03 15:35:58 +0100 | <__monty__> | Yeah, with foldr you can either process every element, or drop whatever's left. |
| 2025-12-03 15:35:01 +0100 | <__monty__> | kuribas`: Show me a foldr that doesn't drop any values and also doesn't visit a tail of several values. |
| 2025-12-03 15:34:46 +0100 | <tomsmeding> | but while that construction is cute, I don't think you get access to the unadulterated tail |
| 2025-12-03 15:34:29 +0100 | <tomsmeding> | base's foldl is implemented using foldr |
| 2025-12-03 15:34:15 +0100 | <tomsmeding> | I know |
| 2025-12-03 15:34:11 +0100 | <__monty__> | tomsmeding: You can implement mapAccumL using foldr. |
| 2025-12-03 15:33:57 +0100 | <tomsmeding> | yeah thinking about this more I'm not sure anymore that you can do this using foldr |
| 2025-12-03 15:33:40 +0100 | <kuribas`> | __monty__: not foldr |
| 2025-12-03 15:33:26 +0100 | <__monty__> | Yep, but foldr and mapAccumL both have to process every element of the structure, no? Since I don't want to outright drop the tail. |
| 2025-12-03 15:33:07 +0100 | Guest35 | (~Guest35@2607:fa49:1940:8200:c958:535b:5462:796d) (Write error: Broken pipe) |
| 2025-12-03 15:32:56 +0100 | <tomsmeding> | but I don't think it's a pre-existing combinator, at least in base |
| 2025-12-03 15:32:43 +0100 | <tomsmeding> | you can implement this with a foldr in a way similar that you can build foldl using foldr |
| 2025-12-03 15:32:17 +0100 | <tomsmeding> | I don't think any of the standard L/R combinators apply here -- the L ones because they continue recursing regardless, and the R ones because the information flow is the wrong way |
| 2025-12-03 15:31:59 +0100 | <__monty__> | Intellectual curiosity mostly. It seems like something that could have an elegant combinator. |
| 2025-12-03 15:31:19 +0100 | <tomsmeding> | do you have a specific reason for wanting this to be a pre-existing combinator? |
| 2025-12-03 15:31:13 +0100 | Googulator40 | (~Googulato@2a01-036d-0106-479c-d9ec-010d-f188-ffcb.pool6.digikabel.hu) |
| 2025-12-03 15:31:08 +0100 | Googulator68 | (~Googulato@2a01-036d-0106-479c-d9ec-010d-f188-ffcb.pool6.digikabel.hu) (Client Quit) |
| 2025-12-03 15:31:00 +0100 | <__monty__> | The output is the same structure and length as the input. I'm pushing a value down into a structure, based on a condition I either push another value down or stop pushing any values down. |
| 2025-12-03 15:30:44 +0100 | Pozyomka | (~pyon@user/pyon) (Quit: brb) |
| 2025-12-03 15:30:44 +0100 | Googulator | (~Googulato@2a01-036d-0106-479c-d9ec-010d-f188-ffcb.pool6.digikabel.hu) (Quit: Client closed) |
| 2025-12-03 15:30:37 +0100 | Googulator68 | (~Googulato@2a01-036d-0106-479c-d9ec-010d-f188-ffcb.pool6.digikabel.hu) |
| 2025-12-03 15:30:28 +0100 | Guest35 | (~Guest35@2607:fa49:1940:8200:c958:535b:5462:796d) |
| 2025-12-03 15:30:15 +0100 | <__monty__> | I don't see how that relates. |
| 2025-12-03 15:30:04 +0100 | <kuribas`> | scanr over tails... |
| 2025-12-03 15:29:38 +0100 | <kuribas`> | scanr? |
| 2025-12-03 15:29:23 +0100 | <__monty__> | I don't think so. Neither direction allows "shortcutting". |
| 2025-12-03 15:29:16 +0100 | <kuribas`> | err |
| 2025-12-03 15:29:04 +0100 | Guest35 | (~Guest35@2607:fa49:1940:8200:c958:535b:5462:796d) (Client Quit) |
| 2025-12-03 15:28:35 +0100 | <lambdabot> | Traversable t => (s -> a -> (s, b)) -> s -> t a -> (s, t b) |
| 2025-12-03 15:28:32 +0100 | <kuribas`> | :t mapAccumR |
| 2025-12-03 15:28:29 +0100 | <kuribas`> | __monty__: sounds like you want mapAccumR |
| 2025-12-03 15:27:59 +0100 | Guest35 | (~Guest35@2607:fa49:1940:8200:c958:535b:5462:796d) |
| 2025-12-03 15:21:01 +0100 | gawen | (~gawen@user/gawen) gawen |
| 2025-12-03 15:17:41 +0100 | chexum | (~quassel@gateway/tor-sasl/chexum) chexum |
| 2025-12-03 15:17:29 +0100 | leah2 | (~leah@vuxu.org) leah2 |
| 2025-12-03 15:17:28 +0100 | chexum | (~quassel@gateway/tor-sasl/chexum) (Remote host closed the connection) |
| 2025-12-03 15:16:54 +0100 | <__monty__> | `mapAccumL` with a Maybe for the state to indicate when the map should fall back to basically `id` feels wrong. |