From: skaller <skaller@maxtal.com.au>
To: STARYNKEVITCH Basile <Basile.Starynkevitch@cea.fr>
Cc: caml-list@inria.fr
Subject: Re: localization, internationalization and Caml
Date: Fri, 15 Oct 1999 08:20:20 +1000 [thread overview]
Message-ID: <38065724.1CEC055F@maxtal.com.au> (raw)
In-Reply-To: <14340.30523.12139.286075@gargle.gargle.HOWL>
STARYNKEVITCH Basile wrote:
>
> By the way, I more and more believe that the printf interface is (in C
> as in Ocaml) a big mistake (which could easily be avoided in Ocaml,
> thanks to it typing)
I agree but ..
> We should code
>
> print [Int 2; String " < "; Float 3.14]
>
> instead of
>
> printf "%d < %g" 2 3.14
However, I do not agree with the solution.
The correct method, IMHO, is to provide some proper formatting
functions (ocamls are plain WRONG!) such as
formatted_string_of_int justify width value
[where justify is LeftSpace | RightSpace | LeftZero]
and then use the power of functional programming
to create output strings. {the above is only a quick exemplary
interface,
not a well considered one]
> Again, I am *not* asking for localization in Ocaml, but if somebody
> needs it (I don't) I still hope it would be implemented better than in
> C. And I think that Unicode would be more useful than localization.
Please, ISO10646 not unicode.
We have International Standards. There is a lot of work to be done in
internationalisation. If it is worth doing, it is worth doing right.
The current 'support' for 8 bit characters in ocaml should be
deprecated immediately. It is an extremely bad thing to have, since
Latin-1 et al are archaic 8 bit standards incompatible with the
international standard for ISO10646 communication, namely
the UTF-8 encoding. Yes, I know Latin-1 is useful now for French.
The way forward may well be to provide an input filter to convert
Latin-1 (or any other encoding) to UTF8, and have ocaml process that.
This requires almost no changes to the compiler: the design should
open the set of characters acceptable in identifiers, probably
to some subset of the set recommended in one of the ISO10646 related
documents; the other change required is to accept \uXXXX and \UXXXXXXXX
escapes in strings. String processing functions should generally
continue to be 8 bit [per octet]: full internationalisation of client
string handling functions is a very complex, non-trivial, task]
next prev parent reply other threads:[~1999-10-15 6:48 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
1999-10-13 12:12 STARYNKEVITCH Basile
1999-10-14 22:20 ` skaller [this message]
1999-10-15 8:26 ` Francis Dupont
1999-10-17 11:27 ` skaller
1999-10-17 15:54 ` Francis Dupont
1999-10-19 18:48 ` skaller
1999-10-15 13:53 Gerard Huet
1999-10-15 20:28 ` Gerd Stolpmann
1999-10-19 18:06 ` skaller
1999-10-20 21:05 ` Gerd Stolpmann
1999-10-21 4:42 ` skaller
1999-10-21 12:05 ` Matías Giovannini
1999-10-21 15:35 ` skaller
1999-10-21 16:27 ` Matías Giovannini
1999-10-21 16:36 ` skaller
1999-10-21 17:21 ` Matías Giovannini
1999-10-23 9:53 ` Benoit Deboursetty
1999-10-25 21:06 ` Jan Skibinski
1999-10-26 18:02 ` skaller
1999-10-17 14:29 ` Xavier Leroy
1999-10-19 18:36 ` skaller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=38065724.1CEC055F@maxtal.com.au \
--to=skaller@maxtal.com.au \
--cc=Basile.Starynkevitch@cea.fr \
--cc=caml-list@inria.fr \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).