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] Camomile-0.5.0
[ 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: Re: [Caml-list] Camomile-0.5.0
From: skaller <>
Subject: Re: [Caml-list] Camomile-0.5.0
Date: 16 Apr 2004 03:22:00 +1000

> I have a question here. The C locale concept does need
> a binding, unfortunately. However it is well known
> this is a seriously deficient hack, and the use
> of C locales should be strongly discouraged.
> C++ uses an imperfect but much better concept: locale's
> are independent objects which can be passed as arguments
> to locale sensitive operations.

Camomile has its own locale, and you can (optionally) pass them to the
locale-sensitive functions.  On the other hand, the functions in
I18N-ed stdlib use C locale *name* to guess the default locale.
Another use of C locale is code-conversion for standard IO.

Binding of C locale functions in Camomile is minimal, just sufficient
to achieve these purpose.  This is because C locale has portability
problems (wch could be even 8-bits, and may not be unicode, and so
on.) and generally weak functionality.  Another reason is that I want
Camomile strictly follow Unicode Standard, while ISO-C does not.

As OCaml on the whole, I think the best strategy would depend on
application.  Desktop applications would required to be consistent
with other C applications, so using OS functions (for example Glib
one, or Win API) would be best.  For a network application, on the
other hand, platform-independence would be desirable.  For such a
case, Camomile like approach (everything implemented by OCaml) would
be better.

Yamagata Yoriyuki

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