[Haskell-cafe] ANNOUNCE: hs-cryptohash 0.4

[Vincent Hanquez]

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