[Haskell-cafe] invalid character encoding

John Meacham john at repetae.net
Sat Mar 19 21:25:41 EST 2005

On Sat, Mar 19, 2005 at 03:04:04PM +0000, Glynn Clements wrote:
> I'm not suggesting inventing conventions. I'm suggesting leaving such
> issues to the application programmer who, unlike the library
> programmer, probably has enough context to be able to reliably
> determine the correct encoding in any specific instance.

But the whole point of Foreign.C.String is to interface to existing C
code. And one of the most common conventions of said interfaces is to
represent strings in the current locale, Which is why locale honoring
conversion routines are useful. 

I don't think anyone is arguing that this is the end-all of charset
conversion, far from it. A general conversion library and parameterized
conversion routines are also needed for many of the reasons you said,
and will probably appear at some point. I have my own iconv interface
which I used for my initial implementation of with/peekCString etc. and
I am sure other people have written their own, eventually one will be
standardized. A general conversion facility has been on the wishlist for
a long time.

However, at the moment, the FFI is tackling a much simpler goal of
interfacing with existing C code, and non-parameterized locale-honoring
conversion routines are extremely useful for that. Even if we had a nice
generalized conversion routine, a simple locale-honoring front end would
be a very useful interface because it is so commonly needed when
interfacing to C code.

However, I am sure everyone would be happy if a nice cabalized general
charset conversion library appeared... I have the start of one here, which
should work on any POSIXy system, even if wchar_t is not unicode (no
windows support though)


John Meacham - ⑆repetae.net⑆john⑈ 

More information about the Haskell-Cafe mailing list