Differences between Traversing/Binding/Fold-Binding Effects in Purescript - purescript

Question

I've been trying to wrap my head around this, I've written four functions that I expect should run the same, I'm curious why they're different.
toEffect :: Tuple Int String -> Effect Unit
toEffect (Tuple i strng) =
log $ append (show i <> ": ") $
statefulPuzzleToString $
selectFirstLadderBruteForce $
parsePuzzle strng
main1 :: Effect Unit
main1 = (toEffect $ Tuple 1 $ fromMaybe "" $ hardestBoardStringsX11 !! 0) >>=
(\_ -> toEffect $ Tuple 2 $ fromMaybe "" $ hardestBoardStringsX11 !! 1) >>=
(\_ -> toEffect $ Tuple 3 $ fromMaybe "" $ hardestBoardStringsX11 !! 2) >>=
(\_ -> toEffect $ Tuple 4 $ fromMaybe "" $ hardestBoardStringsX11 !! 3)
-- ... Pattern could continue for all 11 boards
main2 :: Effect Unit
main2 = do
toEffect $ Tuple 1 $ fromMaybe "" $ hardestBoardStringsX11 !! 0
toEffect $ Tuple 2 $ fromMaybe "" $ hardestBoardStringsX11 !! 1
toEffect $ Tuple 3 $ fromMaybe "" $ hardestBoardStringsX11 !! 2
toEffect $ Tuple 4 $ fromMaybe "" $ hardestBoardStringsX11 !! 3
-- ... Pattern could continue for all 11 boards
main3 :: Effect Unit
main3 = foldl
(\acc new -> acc >>= \_ -> new)
(pure unit)
effects
where
effects :: Array (Effect Unit)
effects = map toEffect $ mapWithIndex Tuple hardestBoardStringsX11
main4 :: Effect Unit
main4 = traverse_ toEffect $ mapWithIndex Tuple hardestBoardStringsX11
For the first two, the console appears to display each effect as it happens. There's maybe upwards of a 1/2second delay between log statements. I'd be extremely surprised to see these behave differently as I understand that the do notation in main2 is just syntactic sugar for what was written in main1
The second two appear log their statements simultaneously.
I'm not entirely certain about main4, but I feel pretty confident that main3 really aught to behave the same as the first two.
Any insight into what's happening here?

Answer 1

Both main3 and main4 behave that way for the same reason, and the reason is the difference between evaluation and execution.
When you have a value of type Effect a, which represents some effect that produces a, presumably you got that value from somewhere. Let's say:
myEffect = makeMeAnEffect "foo"
This value has been evaluated inside makeMeAnEffect, but hasn't yet been executed. Here, "evaluation" means making whatever computation is necessary to produce a value of type Effect a. Creating this value may involve some computation - e.g. multiplying numbers, traversing strings, adding matrices. That's all "evaluation".
But the result of evaluation is a "description" of what should happen when the effect is executed. Here "execution" means "running" the effect, making happen whatever action it describes.
Evaluation and execution are technically separate concepts. Many languages conflate them, but pure functional languages, such as PureScript and Haskell, maintain a strict separation: first you create the description of what should happen ("evaluation"), and then "run" that description ("execution").
This distinction is very important in practice: "evaluation" is pure, which means it's completely unobservable except for its result, and so the compiler can do whatever it wants with it - e.g. optimize, roll/unroll, or even completely drop, - as long as its result stays the same. "Execution", on the other hand, has to be carried out in the exact way that the programmer has specified it, because its whole point is to produce effects, so messing with it will have observable consequences.
In your particular case, in the body of toEffect, evaluation is everything that happens after log $. All those calls to append, selectFirstLadderBruteForce, and so on, - all of that is "evaluation". None of that is effectful. You're performing some computation in order to figure out what sort of effect you're going to create.
And then, once you did all that computation, you pass the result of it to log, and that makes you an Effect Unit, which is a "description of what should happen". And in this particular case, "what should happen" is very small - just write a single string to the console.
And now, finally, we can get to the difference between main1/main2 and main3/main4.
In main1 and main2, you're creating each next effect only after the first one has been executed. So evaluation and execution "overlap", so to speak: first you do fist evaluation, create fist effect, then you run it, and then, only after it's done running, you move on to doing the second evaluation and creating the second effect. And so on. Since the expensive part (in your case) is evaluation, each next execution ends up delayed by however much time the next evaluation takes.
In main3 and main4, on the other hand, you do evaluation first, creating all effects at once by calling map toEffect on an array, and only then you proceed to execute them one by one. And since, again, evaluation (in your case) is the expensive part, and all of it is happening at the beginning, the execution is not delayed. Each effect is very small (just print to console), so they all execute very quickly.
If you really want to prevent the next evaluation from happening until the previous execution is done, you can do this trick: add a pure unit at the beginning of toEffect like so:
toEffect (Tuple i strng) = do
pure unit
log $ append (show i <> ": ") $
statefulPuzzleToString $
selectFirstLadderBruteForce $
parsePuzzle strng
This will make sure that the second line doesn't start evaluating until the first line has executed, thus making each evaluation happen only right before its respective execution.
And finally, another fun fact: in Haskell the same program would work differently, because Haskell is lazy. When asked to do an evaluation, it doesn't do it right away, instead just "remembering" that it's been asked to. And only when the evaluation's result is actually necessary (which would happen on execution), will it be performed.
PureScript, on the other hand, is strict, which means it will always compute everything right away. In this particular case, it means it will compute the whole append etc. series of calls before it can pass their result to log.