Description

-- | Type of a device that can be used to back a 'GHC.IO.Handle.Handle'
-- (see also 'GHC.IO.Handle.mkFileHandle'). The standard libraries provide creation of 'GHC.IO.Handle.Handle's via
-- Posix file operations with file descriptors (see 'GHC.IO.Handle.FD.mkHandleFromFD')
-- with FD being the underlying 'GHC.IO.Device.IODevice' instance.
-- Users may provide custom instances of 'GHC.IO.Device.IODevice' which are expected to conform the following rules:
data IODeviceType
= Directory --^ The standard libraries do not have direct support
-- for this device type, but user implementation is
-- expected to provide a newline-separated list of
-- file names in a directory (without path to the
-- directory itself) in any suitable order,
-- excluding "dot" and "dotdot" names. See
-- also 'System.Directory.getDirectoryContents'.
-- Seek operation is not supported on directories
-- (other than to the zero position).
| Stream --^ A duplex communications channel (results in
-- creation of a duplex 'GHC.IO.Handle.Handle'). The
-- standard libraries use this device type when
-- creating 'GHC.IO.Handle.Handle's for open sockets.
| RegularFile --^ A file that may be read or written, and also
-- may be seekable.
| RawDevice --^ A "raw" (disk) device which supports block binary
-- read and write operations and may be seekable only
-- to positions of certain granularity (block-
-- aligned).
deriving (Eq)

Well, the idea of newline-separated names was that output is immediately printable, and can be tirned into a list of strings using the lines function.

Zero-separated output does not have this property.

OTOH, there was an alternative proposal in my e-mail that the handle could provide a serialized list of FileStatus (or similar) structures, which is slower of course, but if one wants to extract as much file information as possible not worrying about being printable this is IMHO a better (yet complicated) way.