Re: [Caml-list] Common IO classes

[Brian Hurt <bhurt@spnz.org>]

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