On Fri, Jul 02, 2010 at 11:01:17AM -0400, Brandon S Allbery KF8NH wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 7/2/10 07:23 , Vincent Hanquez wrote:
I'm not sure exactly what the API would looks like, but I think basically you would enter/leave the state monad quite frequently in incremental mode, since the whole point of the incremental api is having this context built partially. for this reason, you end up with something really close to explicit state keeping, isn't it ?
You can do this if you need to (execState) but it's better to wrap the whole thing in a State monad. Think of it this way: (flip runState) can be read as "withContext":
flip runState initContext $ do -- do stuff, invoking update as needed to build the state
I think that if the user wants to do that, he would have to build the state monad himself. Fortunately it's a trivial exercise in this case. In my case i'm having a state monad that is not only related to the hashing, but contains more state, so it would not be pratical having to "lift" into the digest context state monad just to update, then got back a context, that i would put in the bigger state monad.
Although now that I think about it, if we're just appending to the state, this should possibly be a Writer instead of a State; the interface is simpler.
Or to try to be a little more concrete about it:
I think that's exactly what i don't want to expose for the simple reason that it's just too easy to shoot self in foot with that. for example, you might be in a situation where the data that you need to hash is really big, and appending Gb of data is not going to fly. In the end, I'ld rather leave this policy to the user, so that a careful user, on controlled case, could implement a writer monad. -- Vincent