Version française
Home     About     Download     Resources     Contact us    
Browse thread
[Caml-list] [ANN] The Missing Library
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Yamagata Yoriyuki <yoriyuki@m...>
Subject: Re: [Caml-list] Re: Common IO structure
From: "Nicolas Cannasse" <warplayer@free.fr>
Subject: Re: [Caml-list] Re: Common IO structure
Date: Tue, 27 Apr 2004 21:08:18 +0200

> - Yamagata Yoriyuki want IO to be on a char basis (and that makes sense for
> Unicode)
> - you would prefer having buffered channels (and that make sense for network
> protocols, parsing, ...)
> - I propose that we have two way of accessing the channel, that can be
> buffered or unbuffered, or others. I think this is enough general to cover a
> lot of different usage, and introduce some interesting polymorphism.
> I would like to get your opinion on that.

I agree buffered I/O for byte-char I/O.  I prefer

object  ... input : string -> int -> int -> int ... end
object  ... output : string -> int -> int -> unit ... end

than your nread/nwrite though. 

I am against buffered I/O for polymorphic channels, because it would
not be easy to come up with a standard for buffer types.  All
arguments for buffered I/O raised in the list are so far about
byte-character I/O (including UTF-8 channels.)

Di-polymorphic channels are interesting, but unless we have a
standard for buffer types, it would not be useful for the standard.
It will be easy to write a mapping from uni-polymorphic channels to
Di-polymorphic channels and vice verse, so IO system of Extlib does
not need to change.  In the future, when Extlib IO is widely used, we
could regard Extlib IO as the standard.

Since we do not have even common Unicode character type, we can not
discuss standardization of Unicode channels.  (one thing at a time!)
Please see my all arguments about Unicode channels as an example of
polymorphic channels.

I still believe my proposal in the previous mail 
  http://caml.inria.fr/archives/200404/msg00716.html 
is reasonable, except for the method names.

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