IterIO type restricted functions
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 enum*f*ile' 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*. Cheers, -John
At Wed, 29 Jun 2011 10:11:26 +1000, John Ky wrote:
[1
] [1.1 ] 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
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,
At Wed, 29 Jun 2011 10:11:26 +1000, John Ky wrote:
[1
] [1.1 ] 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
participants (2)
-
dm-list-haskell-cafe＠scs.stanford.edu -
John Ky