Browse thread
[Caml-list] Common IO classes
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: | 2004-05-25 (19:34) |
From: | Brian Hurt <bhurt@s...> |
Subject: | Re: [Caml-list] Common IO classes |
On Fri, 21 May 2004, Gerd Stolpmann wrote: > Hi list, > > maybe you remember the discussion about common I/O classes. We (Nicolas > Cannasse, Yamagata Yoriyuki and I) continued the thread privately, and > agreed upon the following draft: > > http://www.ocaml-programming.de/tmp/IO-Classes.html > > Maybe other library implementors are interested in a common standard, > and follow this draft (our hope). > I like it. Some comments: - I wish that doing a read or write on a closed channel was required to throw a known, defined, error. This makes actually catching and handling the error possible. As it is, with every library possibly throwing a different exception or even just silently ignoring the error it's impossible to deal with the error. Note that there would still be library-specific exceptions, for library-specific errors. But this is a generic error that all libraries have to deal with, and thus should deal with in the same way. - The problem with returning 0 for non-blocking I/O when no data is available is when someone writes: let really_input chan str idx len = let rec loop idx len = let rval = chan#input str idx len in if rval < len then loop (idx + rval) (len - rval) else () in loop idx len ;; Which busy waits for input. Hmm. Actually, this isn't a diaster, necessarily. Not optimal, granted, but not a diaster. I wouldn't have a problem saying "don't do that!", except I would like some way to determine that I'm dealing with a non-blocking channel, so I know to not do that. - Differing from the precise semantics of the Unix API isn't evil. I'd much rather have it be defined and precise. That way I can at least work around them in a portable way if they don't do precisely what I want. Which my previous example is a demonstration of, by the way. - Polymorphic I/O is defined as blocking, while Octet I/O may be blocking or non-blocking. Say I'm writting a UTF8 -> UCS4 (as int) converter, where I can read 6-7 octet to create one unicode character. How do I work around a non-blocking octet input without busy waiting? -- "Usenet is like a herd of performing elephants with diarrhea -- massive, difficult to redirect, awe-inspiring, entertaining, and a source of mind-boggling amounts of excrement when you least expect it." - Gene Spafford Brian ------------------- To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ Beginner's list: http://groups.yahoo.com/group/ocaml_beginners