[Caml-list] Common IO classes

[Caml-list] Common IO classes

[Gerd Stolpmann]

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).

Gerd
-- 
------------------------------------------------------------
Gerd Stolpmann * Viktoriastr. 45 * 64293 Darmstadt * Germany 
gerd@gerd-stolpmann.de          http://www.gerd-stolpmann.de
------------------------------------------------------------

-------------------
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

Re: [Caml-list] Common IO classes

[Richard Jones]

On Fri, May 21, 2004 at 04:53:39PM +0200, Gerd Stolpmann wrote:
> http://www.ocaml-programming.de/tmp/IO-Classes.html

This seems like a really good proposal.

Will extlib support "I/O" on strings and buffers?

Rich.

-- 
Richard Jones. http://www.annexia.org/ http://www.j-london.com/
Merjis Ltd. http://www.merjis.com/ - improving website return on investment
'There is a joke about American engineers and French engineers. The
American team brings a prototype to the French team. The French team's
response is: "Well, it works fine in practice; but how will it hold up
in theory?"'

-------------------
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

Re: [Caml-list] Common IO classes

[Nicolas Cannasse]

> > http://www.ocaml-programming.de/tmp/IO-Classes.html
>
> This seems like a really good proposal.
>
> Will extlib support "I/O" on strings and buffers?
>
> Rich.

The ExtLib support for this draft is now available into ExtLib (watch the
IOO module).
Regards,

Nicolas Cannasse

-------------------
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

Re: [Caml-list] Common IO classes

[Benjamin Geer]

Gerd Stolpmann wrote:
> 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

Bravo!  It's very encouraging to see this sort of cooperation going on.

Ben

-------------------
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

Re: [Caml-list] Common IO classes

[Brian Hurt]

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

Re: [Caml-list] Common IO classes

[Yamagata Yoriyuki]

From: Brian Hurt <bhurt@spnz.org>
Subject: Re: [Caml-list] Common IO classes
Date: Tue, 25 May 2004 14:41:34 -0500 (CDT)

> - 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.

It was discussed.  Since you can easily extend OO channels to detect
these errors in you favorite way, we do not feel that it is very
important to define the specific exception.

One of the goal of the standard is not to require installing a
specific library.  This makes defining new exceptions in the standard
is impossible.  So what left for us are Failure and Invalid_Arg, both
of which are not very useful.

> - 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?

Non-blocking IO causes the "busy waiting" problem in some layer.  The
non-blocking IO program should use an event-loop, which is outside of
the scope of our standard.

So, it seems for me now, we should make all channels blocking, and if
a channel is blocked in the middle of IO, it should be considered as
an error.  In such a case, the channel would raise Sys_blocked_io and
its state would become undefined.  Recovering from such an error would
be desirable, but enforcing such behavior to all libraries would
technically not easy.  I do not want the standard lay too much burden
to the library developper.

--
Yamagata Yoriyuki

-------------------
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