English version
Accueil     À propos     Téléchargement     Ressources     Contactez-nous    

Ce site est rarement mis à jour. Pour les informations les plus récentes, rendez-vous sur le nouveau site OCaml à l'adresse ocaml.org.

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: 2004-04-26 (15:26)
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: Mon, 26 Apr 2004 16:23:09 +0200

> val create_in :
>   read:(unit -> 'a) ->
>   nread:(int -> 'b) ->
>   pos:(unit -> int) ->
>   available:(unit -> int option) -> close:(unit -> unit) -> ('a, 'b) input
> val create_out :
>   write:('a -> unit) ->
>   nwrite:('b -> unit) ->
>   pos:(unit -> int) ->
>   flush:(unit -> unit) -> close:(unit -> 'c) -> ('a, 'b, 'c) output
> the "minimal set of methods" is 5 methods for both.
> The OO wrappers I proposed are doing exactly what you want , they're
> converting from and to IO input/outputs. Could you explain what part of the
> problem they're not answering ?

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

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

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.

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