Hi, so there are different regions libraries?<br>Is there a shootout comparing them, possibly also with ResourceT from conduit (which has also been implemented in a stand-alone package <a href="http://hackage.haskell.org/package/resource-simple-0.1">http://hackage.haskell.org/package/resource-simple-0.1</a> by Robin Banks), for I take it it tries to respond to the same problem?<br>
<br><div class="gmail_quote">2012/2/23 <span dir="ltr"><<a href="mailto:oleg@okmij.org">oleg@okmij.org</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I have just come across the reddit discussion about regions and<br>
iteratees.<br>
<a href="http://www.reddit.com/r/haskell/comments/orh4f/combining_regions_and_iteratees/" target="_blank">http://www.reddit.com/r/haskell/comments/orh4f/combining_regions_and_iteratees/</a><br>
<br>
There is an unfortunate misunderstanding about regions which I'd like to<br>
correct. I'm posting in Cafe in hope that some of the participants of<br>
that discussion read Haskell-Cafe (I'm not a redditor).<br>
<br>
The user Faucelme wrote:<br>
> Would it be possible to implement a region-based iteratee which opened some<br>
> file "A" and wrote to it, then opened some file "B" and wrote to it, while<br>
> ensuring that file A is closed before file B is opened?<br>
<br>
To which the user tibbe replied<br>
> You can typically explicitly close the files as well.<br>
<br>
and the user dobryak commented<br>
<br>
> Regions that Oleg refers to started out with region-based memory allocation,<br>
> which is effectively a stack allocation strategy, in which resource<br>
> deallocation is in LIFO order. So I think your assumption is correct.<br>
<br>
Regretfully, these comments are incorrect. First of all, memory<br>
regions were invented to get around the stack allocation, LIFO<br>
strategy. If the stack allocation sufficed, why do we need heap? We<br>
have heap specifically because the memory allocation patterns are<br>
complex: a function may allocate memory that outlives it. Regions<br>
let the programmer create arbitrarily many nested regions; everything<br>
in a parent region is available to a child. Crucially, a child may<br>
request any of its ancestors to allocate memory in their<br>
regions. Therefore, although regions are nested, memory does not have<br>
to be allocated and freed in LIFO order.<br>
<br>
The Lightweight monadic regions implement all these patterns for files<br>
or other resources (plus the dynamic bequest).<br>
<a href="http://okmij.org/ftp/Computation/resource-aware-prog/region-io.pdf" target="_blank">http://okmij.org/ftp/Computation/resource-aware-prog/region-io.pdf</a><br>
<br>
The running example of the Haskell Symposium 08 paper was the<br>
following (see sec 1.1)<br>
<br>
1. open two files for reading, one of them a configuration file;<br>
2. read the name of an output file (such as the log file) from the<br>
configuration file;<br>
3. open the output file and zip the contents of both input files into<br>
the output file;<br>
4. close the configuration file;<br>
5. copy the rest, if any, of the other input file to the output file.<br>
<br>
As you can see, the pattern of opening and closing is non-LIFO: the<br>
output file has to be opened after the configuration file and is<br>
closed also after the configuration file. Therefore, the user Faucelme<br>
can find the solution to his question in the code accompanying the<br>
Monadic Regions paper.<br>
<br>
Section 5 of the paper describes even more complex example:<br>
<br>
1. open a configuration file;<br>
2. read the names of two log files from the configuration file;<br>
3. open the two log files and read a dated entry from each;<br>
4. close the configuration file and the newer log file;<br>
5. continue processing the older log file;<br>
6. close the older log file.<br>
<br>
where the pattern of opening and closing is not statically known:<br>
it is decided on values read from the files.<br>
<br>
So, Faucelme's question can be answered in affirmative using the<br>
existing RegionIO library (which, as has been shown, well integrates<br>
with Iteratees). There is already a region library with the desired<br>
functionality.<br>
<br>
<br>
<br>
_______________________________________________<br>
Haskell-Cafe mailing list<br>
<a href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/haskell-cafe" target="_blank">http://www.haskell.org/mailman/listinfo/haskell-cafe</a><br>
</blockquote></div><br>