
On Fri, 2010-07-02 at 20:10 +1000, Ivan Lazar Miljenovic wrote:
Vincent Hanquez
writes: On Fri, Jul 02, 2010 at 12:55:03PM +1000, Ivan Miljenovic wrote:
On 1 July 2010 17:25, Vincent Hanquez
wrote: The main reason for this library is the lack of incremental api exposed by current digest libraries, and filling the void about some missing digest algorithms; Also the speed comes as a nice bonus.
Can you explain what you mean by "incremental API"?
The incremental API is the init/update/finalize functions where you can call update as many time as you need, instead of a single function "hash" where you need to hash all your data in one-go.
It's necessary in my case since i receive chunks of data to be hashed from the network, and I don't want to carry a buffer of data (with potential security issues), until i can hash everything.
The few existing packages that exposes the incremental API, usually do it in the IO monad; cryptohash do it purely, creating a new context as it get updated. (this has a cost but remains fast globally with the C implementation)
i.e. update : ctx -> bytestring -> IO () becomes: update : ctx -> bytestring -> ctx
So you're using explicit state parsing? Any particular reason for not using the State monad or something like that?
Wrapping it into State monad is trivial IMHO but such implementation is trivial to use for example in foldl. Also it allows to not jump in both direction if you need to use it somewhere: f ctx = do l <- getLine let !ctx = update ctx l l <- getLine let !ctx = update ctx l return ctx vs. (if it is forall m. StateT ctx m a) f = execStateT $ do l <- lift $ getLine update l -- Alternativly: update =<< lift (getLine) l <- lift $ getLine update l or f ctx = do l <- getLine let !ctx = execState (update l) l <- getLine let !ctx = execState (update l) return ctx Regards