Re: Common IO structure (was Re: [Caml-list] [ANN] The Missing Library)

[Gerd Stolpmann <info@gerd-stolpmann.de>]

On Son, 2004-04-25 at 10:56, Yamagata Yoriyuki wrote:
> From: "Nicolas Cannasse" <warplayer@free.fr>
> Subject: Re: [Caml-list] [ANN] The Missing Library
> Date: Sat, 24 Apr 2004 11:28:19 +0200
> 
> > There is a beginning of answer in the ExtLib : it's the new IO module that
> > is enabling high-level abstracts inputs/ouputs. http://ocaml-lib.sf.net as
> > usual :-)
> 
> While we are at it...
> 
> Several libraries (Cryptokit, ocamlnet, and Camomile, as far as I
> know) have their own I/O modules.  Could we unify these interfaces?
> IO module of SF Extlib might be a contender, but its channels are
> abstract types, which I think problematic.
> 
> From Camomile perspective, I want channels
> 
> 1) Polymorphic, so that channels can handle Unicode characters
>    directly.
> 
> 2) Based on Objects, so that each library can make an extension of
>    channels while remain compatible with the common interface.
> 
> 3) Light weight.
> 
> Using objects has the extra plus that what we really have to in this
> case is only using the same method name.  We do not need to introduce
> a dependency to the common I/O library.

As you see there are different approaches to tackle similar problems.
Extlib's IO module mainly abstracts over the input and output types, but
it is not extensible. ocamlnet's and camomile's object channels are both
class types, and thus extensible by design. They differ, however, in
what they see as their atoms, i.e. smallest entities read from and
written to a channel, for ocamlnet atoms are strings, for camomile atoms
are characters (char or UChar.t), reflecting a different view what the
libraries regard as important features.

I could imagine ocamlnet and camomile share the same signatures if
camomile would use some kind of polymorphic strings instead.
String-based I/O is much faster than character-based I/O, so camomile
would even profit from this change. However, this unification requires
that we define the algebraic properties of strings and string buffers,
which is not as easy as it sounds.

What we could do at least: Use the same method names for the same
operation, and provide adapters so users can wrap ocamlnet channels as
camomile channels and vice versa. (BTW, the same should be done for our
Unicode strings.)

Gerd

> Just for the reference, I put Camomile OOChannel interface in the
> last.  I'd like to hear the opinion of library developpers.
> 
> (** Generic input/output channel *)
> class type ['a] obj_input_channel = 
>   object 
>     method close : unit 
> 
> 	(** If the channel is already terminated, raise End_of_file *)
>     method get : 'a 
>   end
> 
> class type ['a] obj_output_channel = 
>   object
>     method close : unit
>     method flush : unit
>     method put : 'a -> unit
>   end
> 
> class ['a] channel_of_stream : 'a Stream.t -> ['a] obj_input_channel
> 
> val stream_of_channel : 'a #obj_input_channel -> 'a Stream.t
> 
> class ['a, 'b] filter_in : 
>     ('b obj_output_channel -> 'a obj_output_channel) ->
>       'a obj_input_channel -> 
> 	['b] obj_input_channel
> 
> class ['a] unget : 'a #obj_input_channel ->
>     object
>       inherit ['a] obj_input_channel
>       method unget : 'a -> unit
>     end
> 
> class type char_input_channel =
>   object
>     inherit [char] obj_input_channel
>     method input : string -> int -> int -> int
>     method really_input : string -> int -> int -> unit
>   end
> 
> class type char_output_channel =
>   object
>     inherit [char] obj_output_channel
>     method output : string -> int -> int -> unit
>   end
> 
> class char_input_channel_of : char obj_input_channel -> char_input_channel
> class char_output_channel_of : char obj_output_channel -> char_output_channel
> 
> class of_in_channel : Pervasives.in_channel -> char_input_channel
> class of_out_channel : Pervasives.out_channel -> char_output_channel
> 
> -------------------
> 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
-- 
------------------------------------------------------------
Gerd Stolpmann * Viktoriastr. 45 * 64293 Darmstadt * Germany 
gerd@gerd-stolpmann.de          http://www.gerd-stolpmann.de
------------------------------------------------------------

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