From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id VAA11494; Tue, 25 May 2004 21:34:58 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id VAA12061 for ; Tue, 25 May 2004 21:34:54 +0200 (MET DST) Received: from herd.plethora.net (herd.plethora.net [205.166.146.1]) by concorde.inria.fr (8.12.10/8.12.10) with ESMTP id i4PJYqSH027605 for ; Tue, 25 May 2004 21:34:53 +0200 Received: from bhurt.plethora.net (bhurt.plethora.net [205.166.146.49]) by herd.plethora.net (8.11.6/8.10.1) with ESMTP id i4PJYlG11256; Tue, 25 May 2004 14:34:48 -0500 (CDT) Date: Tue, 25 May 2004 14:41:34 -0500 (CDT) From: Brian Hurt X-X-Sender: bhurt@localhost.localdomain To: Gerd Stolpmann cc: caml-list@inria.fr Subject: Re: [Caml-list] Common IO classes In-Reply-To: <1085151218.30476.125.camel@ice.gerd-stolpmann.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Miltered: at concorde with ID 40B39FDC.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Loop: caml-list@inria.fr X-Spam: no; 0.00; caml-list:01 gerd:01 stolpmann:01 cannasse:01 yamagata:01 yoriyuki:01 silently:01 ignoring:01 generic:01 non-blocking:01 waits:01 non-blocking:01 differing:01 api:01 unicode:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk 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