[Haskell-cafe] Clarifying a mis-understanding about regions (and iteratees)
jwlato at gmail.com
Thu Feb 23 12:49:15 CET 2012
ResourceT really addresses a different problem. Specifically, the
issue of how to guarantee that finalizers will run in the context of
short-circuiting monadic effects. It does this by providing a single
region (not nested regions as Oleg describes) as the base of the monad
stack, ensuring that any short-circuiting effects still need to go
through the ResourceT layer's finalization steps.
Same implementation strategy, different goal.
It doesn't provide nested regions, although you may be able to stack
multiple ResourceT's on top of each other (I have no idea if this
works or not) to do so.
The "regions" package (http://hackage.haskell.org/package/regions) is
another implementation predating ResourceT. I don't know why it never
caught on, except perhaps that at announcement time it was a solution
without a problem.
> From: Yves Par?s <yves.pares at gmail.com>
> Hi, so there are different regions libraries?
> Is there a shootout comparing them, possibly also with ResourceT from
> conduit (which has also been implemented in a stand-alone package
> http://hackage.haskell.org/package/resource-simple-0.1 by Robin Banks), for
> I take it it tries to respond to the same problem?
> 2012/2/23 <oleg at okmij.org>
>> I have just come across the reddit discussion about regions and
>> There is an unfortunate misunderstanding about regions which I'd like to
>> correct. I'm posting in Cafe in hope that some of the participants of
>> that discussion read Haskell-Cafe (I'm not a redditor).
>> The user Faucelme wrote:
>> > Would it be possible to implement a region-based iteratee which opened
>> > file "A" and wrote to it, then opened some file "B" and wrote to it,
>> > ensuring that file A is closed before file B is opened?
>> To which the user tibbe replied
>> > You can typically explicitly close the files as well.
>> and the user dobryak commented
>> > Regions that Oleg refers to started out with region-based memory
>> > which is effectively a stack allocation strategy, in which resource
>> > deallocation is in LIFO order. So I think your assumption is correct.
>> Regretfully, these comments are incorrect. First of all, memory
>> regions were invented to get around the stack allocation, LIFO
>> strategy. If the stack allocation sufficed, why do we need heap? We
>> have heap specifically because the memory allocation patterns are
>> complex: a function may allocate memory that outlives it. Regions
>> let the programmer create arbitrarily many nested regions; everything
>> in a parent region is available to a child. Crucially, a child may
>> request any of its ancestors to allocate memory in their
>> regions. Therefore, although regions are nested, memory does not have
>> to be allocated and freed in LIFO order.
>> The Lightweight monadic regions implement all these patterns for files
>> or other resources (plus the dynamic bequest).
>> The running example of the Haskell Symposium 08 paper was the
>> following (see sec 1.1)
>> 1. open two files for reading, one of them a configuration file;
>> 2. read the name of an output file (such as the log file) from the
>> configuration file;
>> 3. open the output file and zip the contents of both input files into
>> the output file;
>> 4. close the configuration file;
>> 5. copy the rest, if any, of the other input file to the output file.
>> As you can see, the pattern of opening and closing is non-LIFO: the
>> output file has to be opened after the configuration file and is
>> closed also after the configuration file. Therefore, the user Faucelme
>> can find the solution to his question in the code accompanying the
>> Monadic Regions paper.
>> Section 5 of the paper describes even more complex example:
>> 1. open a configuration file;
>> 2. read the names of two log files from the configuration file;
>> 3. open the two log files and read a dated entry from each;
>> 4. close the configuration file and the newer log file;
>> 5. continue processing the older log file;
>> 6. close the older log file.
>> where the pattern of opening and closing is not statically known:
>> it is decided on values read from the files.
>> So, Faucelme's question can be answered in affirmative using the
>> existing RegionIO library (which, as has been shown, well integrates
>> with Iteratees). There is already a region library with the desired
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20120223/b14ad2b2/attachment.htm>
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> End of Haskell-Cafe Digest, Vol 102, Issue 53
More information about the Haskell-Cafe