]]>By: Jeremy Shawhttp://blog.melding-monads.com/2010/07/21/iteratees-and-a-very-minimal-model-of-shared-state-concurrency/#comment-92
Thu, 22 Jul 2010 00:49:16 +0000http://blog.melding-monads.com/?p=287#comment-92Great stuff! These concepts are being used in the latest version of sendfile and happstack now.

For sendfile, the library provides a ‘recursive’ function, but the user needs to be able to do some stuff between each recursion. The user of sendfile library cares about controlling when the function is resumed, and working with the intermediate values. But it does not want to know about the internals of the sendfile function or what data needs to be propogated from one call to the next. The Iter provides a great way of doing this. (And allows us to hide the fact that the data which needs to be propogated is platform dependent).

In happstack, it used so that users can provide functions which process the contents of multipart/form-data and impose quotas, and decide if a value should be stored in RAM or saved on the disk. And, it needs to be able to do it in ‘constant’ space. I have not documented this feature in detail yet but you can see the code here:

In this case, the user provides the function that does the work, but the happstack library needs to do things in-between recursions. But the ‘private’ data which needs to be passed each recursion can be different for different functions. Once again the Iter allows those differences to be wrapped up and hidden. But this time it is so that the library code can avoid having to know the inner details and can work with them in a generic manner.

I still hope to apply the concepts to IxSet so that you can store the keys in RAM, the the values on disk. Haven’t looked at that in detail yet though.