I wasn’t even thinking of IO - I’m very good at avoiding that when possible - what I end up doing is writing giant functions like bigChungus :: a -> a where a is a large agglomeration of mostly auxiliary data, and then I call iterate on it to search for a member of [a] signifying completion, often with a version of find. If you think about it that’s just a loop with the parts of a working as mutable variables.
I have to be suspicious that GHC runtime is actually building such a linked list and not turning that back into a loop in the imperative assembly code, like it should. And really, if I’m writing that way why Haskell.
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.
I wasn’t even thinking of IO - I’m very good at avoiding that when possible - what I end up doing is writing giant functions like
bigChungus :: a -> awhereais a large agglomeration of mostly auxiliary data, and then I calliterateon it to search for a member of[a]signifying completion, often with a version offind. If you think about it that’s just a loop with the parts ofaworking as mutable variables.I have to be suspicious that GHC runtime is actually building such a linked list and not turning that back into a loop in the imperative assembly code, like it should. And really, if I’m writing that way why Haskell.
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 -> binstead so that you don’t have to sort through the result afterwards withfind.I’m not sure exactly what you’re trying to do, but maybe using the
Statemonad could be a good idea? Ifais an object with fields that you want to be able to read and update that sounds a bit like what you might want to useStatefor. 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.