Newest at the top
| 2026-01-08 21:39:06 +0100 | CiaoSen | (~Jura@2a02:8071:64e1:da0:5a47:caff:fe78:33db) CiaoSen |
| 2026-01-08 21:36:56 +0100 | pavonia | (~user@user/siracusa) siracusa |
| 2026-01-08 21:33:55 +0100 | yin | (~zero@user/zero) zero |
| 2026-01-08 21:32:05 +0100 | haritz | (~hrtz@user/haritz) haritz |
| 2026-01-08 21:32:05 +0100 | haritz | (~hrtz@2a01:4b00:bc2e:7000:d5af:a266:ca31:5ef8) (Changing host) |
| 2026-01-08 21:32:04 +0100 | haritz | (~hrtz@2a01:4b00:bc2e:7000:d5af:a266:ca31:5ef8) |
| 2026-01-08 21:31:15 +0100 | merijn | (~merijn@77.242.116.146) (Ping timeout: 240 seconds) |
| 2026-01-08 21:30:55 +0100 | yin | (~zero@user/zero) (Ping timeout: 246 seconds) |
| 2026-01-08 21:30:52 +0100 | Googulator82 | (~Googulato@2a01-036d-0106-4994-68db-cf64-05de-a70a.pool6.digikabel.hu) |
| 2026-01-08 21:30:29 +0100 | Googulator82 | (~Googulato@2a01-036d-0106-4994-68db-cf64-05de-a70a.pool6.digikabel.hu) (Quit: Client closed) |
| 2026-01-08 21:28:11 +0100 | vanishingideal | (~vanishing@user/vanishingideal) vanishingideal |
| 2026-01-08 21:25:56 +0100 | comerijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Read error: Connection reset by peer) |
| 2026-01-08 21:25:50 +0100 | merijn | (~merijn@77.242.116.146) merijn |
| 2026-01-08 21:25:11 +0100 | <EvanR> | larsivi, and foldl' was one of the first things covered in "tutorials" way back when. Once you see this, "primed" versions of other functions start to raise enough eyebrows to not be surprising |
| 2026-01-08 21:24:03 +0100 | <EvanR> | which might be why we still have them |
| 2026-01-08 21:23:53 +0100 | <EvanR> | yes foldl and foldl' are strictly (no pun intended) different beasts and not simply one is a more optimized version of the other |
| 2026-01-08 21:22:30 +0100 | tromp | (~textual@2001:1c00:3487:1b00:a460:d351:8685:d1f0) |
| 2026-01-08 21:22:26 +0100 | peterbecich | (~Thunderbi@71.84.33.135) (Quit: peterbecich) |
| 2026-01-08 21:22:11 +0100 | vanishingideal | (~vanishing@user/vanishingideal) (Ping timeout: 250 seconds) |
| 2026-01-08 21:21:48 +0100 | <Leary> | larsivi: ^ |
| 2026-01-08 21:21:45 +0100 | <lambdabot> | https://github.com/NorfairKing/haskell-dangerous-functions |
| 2026-01-08 21:21:45 +0100 | <Leary> | @where dangerous |
| 2026-01-08 21:21:24 +0100 | tromp | (~textual@2001:1c00:3487:1b00:a460:d351:8685:d1f0) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2026-01-08 21:15:44 +0100 | Googulator82 | (~Googulato@2a01-036d-0106-4994-68db-cf64-05de-a70a.pool6.digikabel.hu) |
| 2026-01-08 21:15:36 +0100 | Googulator82 | (~Googulato@2a01-036d-0106-4994-68db-cf64-05de-a70a.pool6.digikabel.hu) (Quit: Client closed) |
| 2026-01-08 21:15:04 +0100 | newmind | (~newmind@91-133-90-252.dyn.cablelink.at) |
| 2026-01-08 21:00:27 +0100 | <c_wraith> | if it does, the optimizer should be working harder. :) |
| 2026-01-08 21:00:09 +0100 | <dolio> | Yeah. It might make some microscopic difference, but not much. |
| 2026-01-08 20:59:38 +0100 | <c_wraith> | reverse is an example of something where foldl vs foldl' just doesn't matter |
| 2026-01-08 20:59:34 +0100 | <monochrom> | Worst is a monad. pure :: a -> Worst a; join :: Worst (Worst a) -> Worst a. >:) |
| 2026-01-08 20:59:34 +0100 | <tomsmeding> | I'm interested in lists only in this case, but yes :p |
| 2026-01-08 20:59:14 +0100 | <Leary> | tomsmeding: The other countexample is on any traversable that isn't right-biased. |
| 2026-01-08 20:58:58 +0100 | <c_wraith> | you link evaluation of the state to evaluation of the map result, and force each map result sequentially before examining the final state |
| 2026-01-08 20:58:28 +0100 | <c_wraith> | note that mapAccumL *does* have a way to sneak strictness in, and it's the worst possible way |
| 2026-01-08 20:58:02 +0100 | <haskellbridge> | <sm> https://hackage-content.haskell.org/package/infinite-list-0.1.3/docs/Data-List-Infinite.html#v:map… seems to be the strict version |
| 2026-01-08 20:58:00 +0100 | <tomsmeding> | dolio: ah nice, so that's the one counterexample :) |
| 2026-01-08 20:57:55 +0100 | <monochrom> | As usual, a stricter mapAccumL is always welcome, but as usual again, we all vote that someone else should do it. |
| 2026-01-08 20:57:33 +0100 | <lambdabot> | error, called at <interactive>:3:21 in interactive:Ghci1 |
| 2026-01-08 20:57:33 +0100 | <lambdabot> | CallStack (from HasCallStack): |
| 2026-01-08 20:57:33 +0100 | <lambdabot> | *Exception: last: empty list |
| 2026-01-08 20:57:32 +0100 | <dolio> | > foldl' (\_ e -> e) (error "last: empty list") [1,2,3] |
| 2026-01-08 20:57:26 +0100 | <lambdabot> | 3 |
| 2026-01-08 20:57:25 +0100 | <dolio> | > foldl (\_ e -> e) (error "last: empty list") [1,2,3] |
| 2026-01-08 20:57:23 +0100 | <larsivi> | Is there a list of all such things that are improved and shouldn't be used? Preferably with some explanations. |
| 2026-01-08 20:57:15 +0100 | <tomsmeding> | (my post was inspired by optimising an application that, indirectly, applies these list functions to lists millions of elements long) |
| 2026-01-08 20:57:14 +0100 | <c_wraith> | yeah, mapAccumL is like the worst possible strictness behavior. |
| 2026-01-08 20:56:48 +0100 | <monochrom> | Ah. |
| 2026-01-08 20:56:42 +0100 | <tomsmeding> | sm: if the list is not that long it's not that bad of a problem :) |
| 2026-01-08 20:56:15 +0100 | <haskellbridge> | <sm> yikes.. I am using that |
| 2026-01-08 20:56:10 +0100 | <tomsmeding> | monochrom: you could use a state monad, but you should be careful with moving away from plain list functions because you might miss out on fusion RULEs that can cost integer factors in performance |