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