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

["Nicolas Cannasse" <warplayer@free.fr>]

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

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

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

Best 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