I'll make a random comment...
Thanks for the comments!
instance MonadReader s (State s) where ask = get local f m = fmap (fst . runState m . f) get
ahh, hadn't thought of doing that.
You want performance but this pushes more work to the compiler. If this were all functional instead of Monadic it might be simpler to start with.
My code has a lot of values in each record, maps of records, records with lists in them, etc. I actually wrote some of the code without using the state monad to start. It was a little complicated. Rewriting it with the state monad made it more modular and shorter (if you dont count all of the lifters I had to write).
withF1M = withInnerM f1 (\f r -> r {f1=f})
Main *main comment* is to separate manipulating the complex data structure from the State commands. And to make it more abstract:
get1,get3,get4 :: T1 -> Int get2 :: T1 -> T2 get1 = f1
And note the different but important design choice: You don't need to know how the data is nested to access a field.
My code doesnt only operate at the top-most layer. There are some complex state transformations that logically occur on one structure thats nested down several layers. So those operations are most naturally written with a State monad on that object. Other operations are written at a higher layer but may still need access to some lower layer state... So, if I were to follow your suggestion, I would have to make several variations of the accessors/modifiers depending on what level I were to access them from. One reason I went with the lifters was to avoid any blow-up in the number of accessors I had to write (and in hopes that later I can auto-generate them).
If you insert a T1'and'a'half data field "between" T1 and T2 then you just need to update get2/put2 to fix (get|put|mod)(3|4) and this also fixes all the code that uses any of these functions.
Yes. This is a downside. I do have some abstractions that try to hide this occasionally...
-- My choice is to use a strict modify that also returns the new value modify' :: (MonadState a m) => (a -> a) -> m a modify' f = do x <- liftM f get put $! x return x
-- Now tweakT1 can be a one-liner or longer tweakT1,tweakT1'long :: (MonadState T1 f) => Int -> Int -> f Int tweakT1 v1 v3 = liftM get4 (modify' (mod1 (+ v1) . mod3 (+ v3)))
I like it.
The compiler may or may not optimize the mod1 and mod3 into one T1 construction instead of two. If you modify parts 1 and 3 of the state in tandem a lot then
mod13 g1 g3 o@(T1 {f1=v1,f2=v2@(T2 {f3=v3})}) = o {f1=g1 v1,f2=v2 {f3=g3 v3}}
not the prettiest function in the bunch. I can see maybe using something like that if profiling said I really really needed it...
withRead $ withF2R $ withF4R $ ask And that was a very roundabout way to derive liftM get4 == withRead . withF2R . withF4R
true, but its composable and usable at all layers. I could have written "withRead $ withF4R $ ask" in a State T2 a monad or "withRead $ withXXX $ withYYY $ withF2R $ withF4R $ ask" at a much higher level... Thanks for your comments. I need to think over my code to figure out if it makes sense to hide the nestings (I suspect the answer is "sometimes"), but I think I can definitely do that in some cases. I'm starting to think that it might make sense for me to eliminate some of the nesting using cross-references (something simple like an integer ID with maps mapping IDs to objects at the top level). Then perhaps most of my state manipulations will occur at the top level (among having other benefits)... Starting to feel more DB-like. Tim Newsham http://www.thenewsh.com/~newsham/