Hmm no, I can't say that I've ever writen code like that. For one, it might be better to use loop :: (a -> Either a b) -> a -> b instead so that you don't have to sort through the result afterwards with find.

I'm not sure exactly what you're trying to do, but maybe using the State monad could be a good idea? If a is an object with fields that you want to be able to read and update that sounds a bit like what you might want to use State for. This can be combined with maybe something from the loop section of Control.Monad.Extra to make the intention of the code a bit clearer.

If performance is critical you might be better of using a different language anyway (Haskell performance is okay but not amazing) but otherwise I don't think that this is really gonna slow down your code unacceptably much.

[–] [email protected] 2 points 1 year ago

Hmm no, I can’t say that I’ve ever writen code like that. For one, it might be better to use loop :: (a -> Either a b) -> a -> b instead so that you don’t have to sort through the result afterwards with find.

Lol. Yep, I'm a lame Haskeller.

I’m not sure exactly what you’re trying to do, but maybe using the State monad could be a good idea?

This is a pattern that has repeated on different things, and the main reason I haven't done much Haskell in the past couple years. Maybe State is what I need, I'll have to look into it.

If performance is critical you might be better of using a different language anyway (Haskell performance is okay but not amazing) but otherwise I don’t think that this is really gonna slow down your code unacceptably much.

See, I come from a maths background, and I have a bit of perfectionism going even if it's not a big deal. Maybe the processor can do a stupid thing and get away with it, but why should it?

What's that? Valuable programmer time you say? Pffft. I'll be over here designing a chess predicament with a multiply-infinite but well-defined solution to reach check (Yes, I've seen it done).