[MLton] Unicode... again
Wesley W. Terpstra
wesley at terpstra.ca
Fri Feb 9 10:12:45 PST 2007
On Feb 9, 2007, at 5:56 PM, skaller wrote:
>>> Tradeoff between flexibility and safety here..
>>
>> I don't see this point.
>
> The point is people want to work with other charsets and
> encodings whether you like it or not, and for that purpose
> you can choose whether to let them use the string type,
> or force them to use a raw encoding like (Word8Vector?)
That's what I plan to do. If it's in a String, it is supposed to be
only values with code point < 256. If you want to work with some
encoded text, well that's a blob. Blobs are Word8Vector.vector. We
will be providing a function similar to iconv that allows incremental
conversion of WideChar <-> Word8. If I recall, we were planning to do
it similar to the ('a, 'b) reader types used already in SML.
> However if you want to read strings
> from files in UTF-8 format (at run time i mean)
> you can get errors, and if you want
> to do it FAST you cannot detect them: validating the input
> isn't really an option (it will cause a whole extra pass
> on the file which is WAY too expensive).
I don't see how this is any different from parsing any input in
general. You can incrementally parse it, and when an error occurs
your parser reports an error. By using the SML ('a, 'b) reader
abstraction, you can just compose a UTF-8/whatever decoder up to a
BinIO stream and connect that in turn to your parser. MLton will
inline all the abstraction anyway. :-)
As an aside: I've made WideChar = 16/32 bits a compiler flag, similar
to how the default int type is chosen.
More information about the MLton
mailing list