Hi, I'm not quite sure how to describe this concept in Haskell, so let me first start by describing a feature of Python I find very useful. In Python, a file handle is just another object. It has certain methods that Python programmers expect to find: read(), readlines(), write(), writelines(), seek(), tell(), etc. This is useful because even things do not correspond to OS-level file descriptors can be accessed as files. In Python, this is used so that a file-like interface is available for gzip/gunzip interfaces, strings, SSL connections, bzip2, files from FTP, etc. That means that almost any function designed to work with an on-disk file could also work transparently read from a gzipped file, a string, etc. I think it would be useful to have this sort of abstraction in Haskell. However, I can't really see any way to tie into the Handle system; from what I can tell, it seems to be hooked in with the underlying OS at a fairly low level. One alternative would be to provide a typeclass that provides equivolents for most of the functions that work on a Handle. Making a Handle a member of that class would be trivial. We could also extend the concept a bit so that we could have separate classes for certain features that not all file-like things would support -- for instance, some function could have this type: fooFunc :: SeekableHandle a => a -> IO String So, I'm wondering: 1. Has anybody already done work on this? If so, is there any consensus on which implementations are most useful? Are there any known problems with existing implementations? 2. Is this something that could eventually make its way into the standard hierarchical libraries? If I were to implement it -- and it sounds fairly easy to do -- do you have any suggestions for me? Thanks, John
On Fri, 22 Oct 2004, John Goerzen wrote:
In Python, a file handle is just another object. It has certain methods that Python programmers expect to find: read(), readlines(), write(), writelines(), seek(), tell(), etc. This is useful because even things do not correspond to OS-level file descriptors can be accessed as files. In Python, this is used so that a file-like interface is available for gzip/gunzip interfaces, strings, SSL connections, bzip2, files from FTP, etc. That means that almost any function designed to work with an on-disk file could also work transparently read from a gzipped file, a string, etc.
If all of these objects can be represented as Strings or at least as Lists in many cases you only need a function that reads or writes the complete disk object, such as readFile and writeFile. You can apply all string or list functions respectively on the contents of the file and lazy evaluation assures a streaming behaviour of the complete process. Though I'm afraid, seeking won't work this way.
On Friday 22 October 2004 10:05 am, Henning Thielemann wrote:
On Fri, 22 Oct 2004, John Goerzen wrote: If all of these objects can be represented as Strings or at least as Lists in many cases you only need a function that reads or writes the complete disk object, such as readFile and writeFile. You can apply all string or list functions respectively on the contents of the file and lazy evaluation assures a streaming behaviour of the complete process. Though I'm afraid, seeking won't work this way.
That also won't work for bidirectional things, such as network communications, disk files opened read/write, gzip files, etc. -- John
participants (2)
-
Henning Thielemann -
John Goerzen