RE: H98 FFI Addendum 1.0, Release Candidate 15
And here now a probably naive question of mine: Does the notion of Marlow sensibility coincide with platforms that follow ISO/IEC 10646?
We don't want to restrict the standard to sensible systems, because that rules out Windows :-). On Windows, wchar_t is UTF-16, which is a profoundly silly situation and seems to be the main reason that UTF-16 exists at all, but there's not much we can do about that. So, the standard should say that the system converts appropriately between Haskell's Unicode Char and whatever the system's encoding for wchar_t is. We don't want castCharToCWchar, because the encoding of a Char into wchar_t might result in multiple wchar_ts. In practice, I'm not sure we'll have the energy to implement this properly. We might get around to implementing a UTF-16 conversion for Windows, but for Unix systems I imagine we'll restrict ourselves to sensible systems. Cheers, Simon
"Simon Marlow" <simonmar@microsoft.com> wrote,
And here now a probably naive question of mine: Does the notion of Marlow sensibility coincide with platforms that follow ISO/IEC 10646?
We don't want to restrict the standard to sensible systems, because that rules out Windows :-).
What a nice definition of sensible systems ;-)
So, the standard should say that the system converts appropriately between Haskell's Unicode Char and whatever the system's encoding for wchar_t is. We don't want castCharToCWchar, because the encoding of a Char into wchar_t might result in multiple wchar_ts.
Ok. This seems to coincide what John wrote in his reply to my message. The spec at the moment says, To simplify bindings to C libraries that use \code{wchar\_t} for character sets that cannot be encoded in byte strings, the module \code{CString} also exports a variant of the above string marshalling routines for wide characters. How shall this text be amended? Is the following sufficient? These marshalling routines convert Haskell's Unicode representation for characters into the platform-specific encoding used for \code{wchar\_t} and vice versa. In particular, on platforms that represent \code{wchar\_t} values according to the encoding specified by ISO/IEC 10646, this conversion reduces to a simple type cast without any alteration of the character values. For all other platforms, the exact rules of the conversion are platform-specific and not further defined in this report. Does anybody have any suggestions for improving this explanation? Cheers, Manuel
On Fri, Nov 14, 2003 at 01:57:41PM +1100, Manuel M T Chakravarty wrote:
These marshalling routines convert Haskell's Unicode representation for characters into the platform-specific encoding used for \code{wchar\_t} and vice versa. In particular, on platforms that represent \code{wchar\_t} values according to the encoding specified by ISO/IEC 10646, this conversion reduces to a simple type cast without any alteration of the character values. For all other platforms, the exact rules of the conversion are platform-specific and not further defined in this report.
Does anybody have any suggestions for improving this explanation?
I don't think we need to say anything special, the conversion to wchar_t * is just as defined as that to char *. it is a locale dependent operation just like withCString and friends. one would make their decision as to which to use based on the library they are trying to bind too, if a wchar_t interface is supported it should be prefered because it is more likely to preserve character codes. John -- --------------------------------------------------------------------------- John Meacham - California Institute of Technology, Alum. - john@foo.net ---------------------------------------------------------------------------
participants (3)
-
John Meacham -
Manuel M T Chakravarty -
Simon Marlow