Newest at the top
| 2025-12-03 16:04:45 +0100 | amadaluzia | (~amadaluzi@user/amadaluzia) amadaluzia |
| 2025-12-03 16:04:39 +0100 | <kuribas`> | --proof that it doesn't visit the tail :) |
| 2025-12-03 16:04:26 +0100 | <lambdabot> | [2,4,6,8,10,6,7,8,9,10] |
| 2025-12-03 16:04:23 +0100 | <kuribas`> | > take 10 $ foldr (\(x:xs) cont -> \xs2 -> if (x > 5) then (x:xs) else (x*2) : cont xs) id (tails [1..]) [] |
| 2025-12-03 16:03:03 +0100 | spew | (~spew@user/spew) spew |
| 2025-12-03 16:02:40 +0100 | lucabtz | (~lucabtz@user/lucabtz) (Remote host closed the connection) |
| 2025-12-03 16:01:59 +0100 | ttybitnik | (~ttybitnik@user/wolper) (Quit: Fading out...) |
| 2025-12-03 16:01:28 +0100 | divlamir | (~divlamir@user/divlamir) (Ping timeout: 244 seconds) |
| 2025-12-03 16:00:45 +0100 | spew | (~spew@user/spew) (Ping timeout: 245 seconds) |
| 2025-12-03 16:00:00 +0100 | <kuribas`> | obviously needs some lambdacase. |
| 2025-12-03 15:59:41 +0100 | <kuribas`> | ^ __monty__ |
| 2025-12-03 15:59:36 +0100 | <lambdabot> | [2,4,6,8,10,6,7,8,9,10] |
| 2025-12-03 15:59:30 +0100 | <kuribas`> | > foldr (\(x:xs) cont -> \xs2 -> if (x > 5) then (x:xs) else (x*2) : cont xs) id (tails [1..10]) [] |
| 2025-12-03 15:51:23 +0100 | wbooze | (~inline@cgn-195-14-221-120.nc.de) Inline |
| 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. |