On 26 Sep 2007, at 7:05 pm, Johan Tibell wrote:
If UTF-16 is what's used by everyone else (how about Java? Python?) I
think that's a strong reason to use it. I don't know Unicode well
enough to say otherwise.
Java uses 16-bit variables to hold characters.
This is SOLELY for historical reasons,
On 9/27/07, ok [EMAIL PROTECTED] wrote:
(What the heck _is_ Tangut, anyway?)
http://en.wikipedia.org/wiki/Tangut_language
Juanma
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
I'll look over the proposal more carefully when I get time, but the
most important issue is to not let the storage type leak into the
interface.
Agreed,
From an implementation point of view, UTF-16 is the most efficient
representation for processing Unicode. It's the native Unicode
On Wed, 2007-09-26 at 09:05 +0200, Johan Tibell wrote:
I'll look over the proposal more carefully when I get time, but the
most important issue is to not let the storage type leak into the
interface.
Agreed,
From an implementation point of view, UTF-16 is the most efficient
In message [EMAIL PROTECTED] Jonathan Cast [EMAIL PROTECTED] writes:
On Wed, 2007-09-26 at 09:05 +0200, Johan Tibell wrote:
If UTF-16 is what's used by everyone else (how about Java? Python?) I
think that's a strong reason to use it. I don't know Unicode well
enough to say otherwise.
I
On Wed, 2007-09-26 at 18:46 +0100, Duncan Coutts wrote:
In message [EMAIL PROTECTED] Jonathan Cast [EMAIL PROTECTED] writes:
On Wed, 2007-09-26 at 09:05 +0200, Johan Tibell wrote:
If UTF-16 is what's used by everyone else (how about Java? Python?) I
think that's a strong reason to use
Hi, thanks for proposal,
Why questions connected with converting are considered only?
The library i18n should give a number of other services such as
normalization, comparison, sorting, etc.
Furthermore it's not so easy to keep such library up to date.
Why simply do not make a bindings to IBM ICU
I'll look over the proposal more carefully when I get time, but the
most important issue is to not let the storage type leak into the
interface.
From an implementation point of view, UTF-16 is the most efficient
representation for processing Unicode. It's the native Unicode
Dear haskell-cafe,
I would like to propose a new, ByteString like, Unicode string library
which can be used where both efficiency (currently offered by
ByteString) and i18n support (currently offered by vanilla Strings)
are needed. I wrote a skeleton draft today but I'm a bit tired so I
didn't
Johan Tibell wrote:
Dear haskell-cafe,
I would like to propose a new, ByteString like, Unicode string library
which can be used where both efficiency (currently offered by
ByteString) and i18n support (currently offered by vanilla Strings)
are needed. I wrote a skeleton draft today but I'm a
10 matches
Mail list logo
