Removes thunk in decoder, causes infinite loop

[agj]

Hello! I've found a corner case when simplifying decoders.

The above simplification looks fine at first glance. The problem is that it actually changes the meaning of the code. There's a reason this decoder was written this way, using a thunk: this snippet of code lives inside the compose function, and after simplification, it will cause the function to recursively call itself in an infinite loop.

[jfmengels]

Hey 👋

Thank you for reporting 🙏
I agree that this is a bug. On top of this recursion issue, this can also have a performance impact, where you might want to evaluate an expensive computation the lambda lazily. I have seen this mostly for Parser.map.

I think adding an exception (not applying map f (succeed x) -> succeed (f x)) to some of the map functions where the value can be evaluated lazily. For the others, I don't think it changes anything to apply the change. For instance, Maybe.map f (Just x) will evaluate eagerly anyway.

So I think the exception should be made for:

• Json.Decode.map
• Json.Decode.mapN? 🤔
• Parser.map (and Parser.Advanced.map) (though this is not implemented yet anyway)
• Task.map
• Task.mapError? 🤔
• Platform.Cmd.map
• Platform.Sub.map
• Random.map? 🤔