[lexi-lambda]

I don’t think the complaints about evaluation order in this blog post really make sense. The evaluation order of `map` in SML is no more mysterious than the evaluation order of `mapM` in Haskell. The use of explicit monadic sequencing has its advantages (as well as nontrivial disadvantages), but this is not one of them. This is particularly true if `mapM` is written using applicative functors, as the definition

    mapM :: Monad m => (a -> m b) -> [a] -> m [b]
    mapM f []     = return []
    mapM f (x:xs) = (:) <$> f x <*> mapM f xs

is virtually identical in structure to the SML definition

    fun map f []        = []
      | map f (x :: xs) = op:: (f x) (map f xs)

aside from the “plumbing” of `return`, `<$>`, and `<*>`. Indeed, the whole motivation of applicative functors, as well as the source of their name, was a desire to write code in a form closer to an applicative style, which is to say non-monadic, direct-style code like the SML example. The blog post says

> Does it print the values in forward or reverse order? One could implement it either way.

but obviously this is also true of `mapM`. That would just be a different function. Monadic sequencing does not help with this at all.

Furthermore, the author mentions algebraic effect systems. It isn’t clear to me from the wording if the intent is to offer them as a solution for the shortcomings of monadic encodings or as a nicer way to pin down evaluation order, but the latter is certainly not true—the two are entirely orthogonal. Algebraic effect systems depend on the evaluation order being well-defined by other means to work in the first place. In fact, one could argue that the entire point of algebraic effect systems is to allow the composition of different effects while respecting an underlying notion of evaluation order.