Hi David,<div><br></div><div>Good point. Not too fussed, though now that I think about it, I would have preferred it if <font class="Apple-style-span" face="'courier new', monospace">enumFile'</font> was defined in the tutorial rather than in the module.</div>
<div><br></div><div>Cheers,</div><div><br></div><div>-John<br><br><div class="gmail_quote">On 29 June 2011 13:53, <span dir="ltr"><<a href="mailto:dm-list-haskell-cafe@scs.stanford.edu">dm-list-haskell-cafe@scs.stanford.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">At Wed, 29 Jun 2011 10:11:26 +1000,<br>
John Ky wrote:<br>
><br>
> [1 <multipart/alternative (7bit)>]<br>
> [1.1 <text/plain; ISO-8859-1 (7bit)>]<br>
<div><div></div><div class="h5">><br>
> Hi all,<br>
><br>
> From the IterIO tutorial:<br>
><br>
> enumFile' is like enumFile above, but type restricted to data in the lazy<br>
> ByteString format, which is more efficient than plain Strings. (enumFile<br>
> supports multiple types, but in this example there is not enough<br>
> information for Haskell to choose one of them, so we must use enumfile' or<br>
> use :: to specify a type explicitly.<br>
><br>
> Which is fine, but shouldn't there also be iterHandle' and iterStream'?<br>
><br>
> Also I'm guessing the f is a typo that should be F.<br>
<br>
</div></div>Thanks, just fixed the typo in git.<br>
<br>
I guess the logic is that these are super-easy to define in your own<br>
code, so better not to pollute the namespace with lots of symbols.<br>
<br>
The same logic also applies to enumFile'. However, in testing I found<br>
that I often wanted something like enumFile' to prototype something<br>
quick and dirty, just to test from a file. So I added it as a<br>
convenience to myself.<br>
<br>
I don't have very strong feelings either way. If enumFile' is<br>
inconsistent, my inclination would be to get rid of enumFile' rather<br>
than add iterHandle' etc. That way, if someone wants to do everything<br>
in terms of strict byte strings, or text, or whatever, then can just<br>
define the primed versions to be whatever data format they prefer.<br>
<br>
I guess the reason it doesn't feel to horrible as-is is that enumFile<br>
is already a convenience function effectively combining openFile with<br>
enumHandle.<br>
<br>
David<br>
</blockquote></div><br></div>