Re: [Caml-list] Re: Common IO structure

[Yamagata Yoriyuki <yoriyuki@mbg.ocn.ne.jp>]

From: "Nicolas Cannasse" <warplayer@free.fr>
Subject: Re: [Caml-list] Re: Common IO structure
Date: Mon, 26 Apr 2004 21:28:53 +0200

> > You miss my point.  What I propose is having agreement over I/O
> > channels.  So, having OO wrappers only solves the half of our
> > problems.  Another half is whether or not developpers accept
> > them.
> >
> > And from my point of view, your proposal has some problems.  For one
> > thing, it is not compatible to the already existing I/O channels in
> > other libraries than Extlib.  Camomile uses get and put for your read
> > and write, and ocamlnet and cryptokit uses input and output (IIRC) for
> > your nread and nwrite.
> 
> So ? That's exactly what we're talking about it there : making a choice. And
> that include naming of course. I don't say that the name we choosed for
> ExtLib IO are better, it's just that "reading" and "writing" on an IO seems
> natural to me.

get/put are used in Camomie already, and input/output are used in
ocamlnet.  OO wrappers of Extlib IO are only recent addition, so
changing Extlib is more natural.  In this case, what Extlib should do is
just changing OO wrappers.  I do not think you need to change IO
module itself.

> 
> > Another problem is that it is not minimal
> > enough.  For character converters, it is impossible to predict how
> > many characters will be available, for example.  And requiring "pos",
> > "nread", "nwrite" seems arbitrary for me.  They are somtimes useful
> > and improvement, but not necessary.
> 
> That's true, I agree with you but on the last point : they are necessary in
> order to get good performances. Concerning "available", it returns None if
> no data available. "pos" might throw an exception as well when unavailable
> (looks like pos and available should have same behavior here).

My philosophy is to make the type informative as far as possible.  If
some method does not work, I would rather remove the method, and
notify this fact to a user in the compile time (not in the runtime).  A
user, or the library developer can provide wrappers if necessary.

Philoshophy aside, I do not see how pos and available improve
performance.  pos certainly decreases performance.  Anyways disks are
much slower than CPU, so arguing small performance benefit is
nonsense.  Since there are many possible "improvements" (seek, unget,
length, destination addresses), it would be better to stick the
algebraically minimal specification.

Note that I do not oppose extension as such.  I oppose making them as
the standard.

> And nread/nwrite can simply call n times read/write. That means that
> any library can put default implementation for additional "not
> minimal" constructs : they will behave poorly (writing a string char
> by char) but will interface well with other IO that are supporting
> them correctly. If implementing efficently nread/nwrite require
> additionnal effort, then let's implement a default behavior and
> implement it better later. Having theses functions make room for
> future improvements, which is not done with minimal IO.

Choosing a type of buffers is not trivial (except char, in this case I
propose using stirng, of courst).  For exmaple, what is for a Unicode
channel?  UTF8/UTF16/UTF32 strings, array, DynArray.t, all have their
own advantage.  And if someone uses UTF8, another uses UTF16 and so
on, then there is not much point of having standard.

Of course we would make "nread/nwrite" use a default buffer type
(maybe list, as you do Extlib), but I doubt that such "filler" methods
do any good.

For extensibility, it is guaranteed when we agreed to use object.  As
I stated above, I do not oppose using extension of channel types.
What I propose is just to make channels in each library an extension
of "standard" channel objects, and to make standard channel work as an
argument to the library API as far as possible.  (or provide a
converter)

> 
> > Since I want that these interfaces are accepted as the common
> > standard, I wanted that the requirement is absolutely minimal.  My
> > proposal in the previous mail is inspired by the view that channels
> > are co-inductive types defined by its constructer and consumer.
> > Without those methods, they are not channels any more.
> >
> > I'm interested in your opinion.
> 
> Mapping several IO ( a zlib compression + a base64 encoding + a unicode
> reader ) and using them all together to read and write chars will definitly
> slow down. Buffering is our friend, and require some more constructs.

For characters, I have proposed bufferd IO.

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