On Oct 25, 2009, at 5:01 PM, Curt Sampson wrote:
Actually, you would be having the exact same issues with Java; in
UTF-8
mode it would also choke on Latin-1.
Yes, but from the 'javac' man-page:
-encoding encoding
Sets the source file encoding name,
such as
EUCJIS/SJIS/ISO8859-1/UTF8. If -encoding is not
specified, the
platform default converter is used.
The corresponding part of the GHC documentation says
GHC assumes that source files are ASCII or UTF-8 only,
other encodings are not recognised. However,
invalid UTF-8 sequences will be ignored in comments,
so it is possible to use other encodings such as Latin-1,
as long as the non-comment source code is ASCII only.
There's no obvious reason why GHC couldn't support any source
encoding that the host's iconv() supports.
Blaming Haskell for this
"problem" is quite unfair.
It is perfectly fair. The problem is not that the original user
isn't telling GHC what the encoding is, but that GHC cannot be
told. A javac-like -encoding switch on the command line would
meet the original need.
(If all of this UTF-8 stuff seems annoying to you, consider that in
ISO-8859-1 it's not possible to express the simplest Japanese word.
And why, exactly, should someone who has no Japanese words to express
even care? You have explained why UTF-8 is a good *default*; that
does not make choosing it as the *only* option a good idea.
_______________________________________________
Haskell-Cafe mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/haskell-cafe
