Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

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: Nicolas Cannasse <warplayer@f...>
Subject: Re: [Caml-list] Re: Common IO structure
> > > 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.
> > 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
> > natural to me.
> That sounds like a paraphrase for "better" without using this word. I
> would like to hear real arguments for why certain names should be used.
> For example, one reason can be that there is already a user base.
> I think names are just names, and there are usually several ways of
> referring to things. However, when several independent libraries
> _choose_ to name their methods in a coherent way, I would say this is
> very intelligent.

I agree with you.
Let's agree on something consistent : naming is a non-issue.

> > > 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
> > order to get good performances. Concerning "available", it returns None
> > no data available. "pos" might throw an exception as well when
> > (looks like pos and available should have same behavior here). And
> > nread/nwrite can simply call n times read/write. That means that any
> > can put default implementation for additional "not minimal" constructs :
> > they will behave poorly (writing a string char by char) but will
> > well with other IO that are supporting them correctly. If implementing
> > efficently nread/nwrite require additionnal effort, then let's implement
> > default behavior and implement it better later. Having theses functions
> > room for future improvements, which is not done with minimal IO.
> Guess what? ocamlnet implements all that in a convincing way. Read its
> introduction to OO wrappers for I/O:

We're actually quite near to agree on what should be the minimal
Looks like you included pos_in / pos_out into the "fundamentals methods" ,
would you agree to drop theses ?

In short, I think we all want different things :
- Yamagata Yoriyuki want IO to be on a char basis (and that makes sense for
- 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.

Best Regards,
Nicolas Cannasse

To unsubscribe, mail Archives:
Bug reports: FAQ:
Beginner's list: