Ben Rudiak-Gould writes: > Must contexts be used in a single-threaded manner? If so, > I would expect this interface:
> start :: IO ctx > feed :: ctx -> Buffer -> IO () > commit :: ctx -> IO a 'feed' cannot have this signature because it needs to update the context. > If not, I would expect this interface: > start :: ctx > feed :: ctx -> Buffer -> IO ctx > commit :: ctx -> a Both 'start' and 'commit' need to be in the IO monad, because creating and finalizing the context may involve IO calls. (Just think of a computation that does internal buffering in memory which is accessed through another Ptr.) > Additionally, I don't think (Ptr Word8, Int) is general > enough for all reasonable uses of this interface. That's true. I used this because I have the data in a memory buffer already, so this is the API with the best performance for me because it handles the input without marshaling. I agree it would be nice to have something more general and generally smarter than the my type definition -- that's why I asked on the list. :-) > feedBuffer :: ctx -> Buffer -> IO ctx > feedSTUArray :: ctx -> STUArray s Int Word8 -> ST s ctx > feedUArray :: ctx -> UArray Int Word8 -> ctx I would implement feedSTUArray and friends as wrappers around the Ptr interface, not as primitive computations of the stream processor. But nonetheless, having those would be nice. Peter _______________________________________________ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
