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