At 2001-08-13 08:29, Marcin 'Qrczak' Kowalczyk wrote:
>Fri, 10 Aug 2001 18:31:24 -0700, Ashley Yakeley <ashley(a)semantic.org> pisze:
>
>> I can only tell you what's useful for me as an API user. Since there are
>> peculiar little differences between different kinds of sockets, my ideal
>> would be every type of socket to have its own API functions, and then
>> common patterns brought together with classes.
>
>It makes harder to program polymorphically. In particular having
>a heterogeneous datastructure requires wrapping different types
>in either function closures or existential types, thus awkwardly
>emulating the current interface.
Do you have an example? Can't you simply substitute something like
"(Connection c) => c" for "Handle"?
>Items which are used interchangeably shouldn't have different types
>in a language like Haskell which doesn't provide subtyping.
Isn't that what classes are for? I've noticed that the more I use
Haskell, the less I miss subtyping... classes and "data" unions are
almost always sufficient. But perhaps you have an example which would
really want subtyping, given an API for which every type of connection
handle had its own type.
...
>> But at the very least, separate out files from sockets. I'm really
>> not sure why files have a "file pointer" stream-based API at all.
>
>Because it's convenient. Files are usually read sequentially.
Files are mostly read in their entirety: but sometimes they are read in
sequentially (e.g. parsers), and very occasionally read in "randomly"
(e.g. pointer-based formats such as TIFF, or databases and the like).
My solution would be to have the API "random-access" based, and then have
a type that provided the current stream-based interface (which I would
use for your example):
--
data FileStream = MkFileStream
{
fsFile :: OpenFile,
fsPointer :: Integer
}
instance Closable FileStream where
...
instance Source FileStream where
...
instance Sink FileStream where
...
--
With the current API, one can provide a "random-access" based interface
something like this:
--
data OpenFile = MkOpenFile
{
ofHandle :: Handle,
ofLock :: ThreadLock -- or whatever
}
readFileBlock :: OpenFile -> Integer -> Integer -> IO [Word8]
readFileBlock file start length = synchronized (ofLock file) do
{
let {handle = ofHandle file};
hSeek handle AbsoluteSeek start;
... repeatedly call hGetChar handle ...
}
... etc.
--
...provided a way of shortening a file was provided and the API used
Word8s instead of Chars. This just seems a whole lot uglier.
I don't know much about Haskell's multithreaded support, but if one
wanted multiple threads using the same file, you'd need some kind of
thread-locking (as suggested above). By contrast, with a "random-access"
API it might even be possible to allow multiple simultaneous read
operations.
But I admit my preference is essentially aesthetic. Files are by nature
accessible at any point, but we choose to pretend that they are streams
(because that's convenient most of the time) and then we have to jump
through hoops to make the streaminess go away when want actual direct
access to arbitrary offsets.
My preference for libraries is for interfaces that reveal the true nature
of the object as accurately as possible, and to make explicit all the
little patterns and conversions that programmers like to use. I believe
Haskell is powerful enough to do this cleanly even without subtyping...
the advantage is essentially the same advantage as strong typing: more
errors are caught at compile-time. You can no longer write to standard
input, or seek on a TCP connection, or get the remote IP address of an
AppleTalk connection, etc.
--
Ashley Yakeley, Seattle WA
