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: Yamagata Yoriyuki <yoriyuki@m...>
Subject: [Caml-list] Re: Common IO structure
From: Gerd Stolpmann <>
Subject: Re: Common IO structure (was Re: [Caml-list] [ANN] The Missing Library)
Date: Sun, 25 Apr 2004 13:54:01 +0200

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

When I did a compatison, the speed of Camomile code converter is in
the same order of iconv (EUC-JP -> UTF8 2-times slower, UTF8 -> EUC-JP
50% faster).  I doubt that char-based I/O is significantly slower,
unless operation is very simple.  String-based I/O has to manage
buffer strings, which causes extra cost, and anyways the major cost
comes from elsewhere.  (For code converters, the major cost is caused
by table lookup.)

That said, I plan to add string-based I/O for character channels,
partially to interpolate C fucitons.  So, for character channels,
Camomile would be compatible ocamlnet.

Yamagata Yoriyuki

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