On Mon, Sep 13, 2004 at 12:01:58PM +0100, Glynn Clements wrote:
My view is that, right now, we have the worst of both worlds, and
taking a short step backwards (i.e. narrow the Char type and leave the
rest alone) is a lot simpler (and more feasible) than the long journey
towards real I18N.
I've not been following this debate, but I think I agree with Ross.
In particular, the idea of narrowing the Char type really seems like a
bad idea to me (if I understand the intent correctly). Not so long ago, I
did a whole load of work on the HaXml parser so that, among other things,
it
Glynn Clements [EMAIL PROTECTED] writes:
Unless you are the sole user of a system, you have no control over
what filenames may occur on it (and even if you are the sole user,
you may wish to use packages which don't conform to your rules).
For these occasions you may set the encoding to
Marcin 'Qrczak' Kowalczyk wrote:
Unless you are the sole user of a system, you have no control over
what filenames may occur on it (and even if you are the sole user,
you may wish to use packages which don't conform to your rules).
For these occasions you may set the encoding to
Udo Stenzel wrote:
Note that this needs to include all of the core I/O functions, not
just reading/writing streams. E.g. FilePath is currently an alias for
String, but (on Unix, at least) filenames are strings of bytes, not
characters. Ditto for argv, environment variables, possibly
Glynn Clements [EMAIL PROTECTED] writes:
[Actually, regarding on-screen display, this is also an issue for
Unicode. How many people actually have all of the Unicode glyphs?
I certainly don't.]
If I don't have a particular character in fonts, I will not create
files with it in filenames.
Glynn Clements [EMAIL PROTECTED] writes:
3. The default encoding is settable from Haskell, defaults to
ISO-8859-1.
Agreed.
So every haskell program that did more than just passing raw bytes
From stdin to stdout should decode the appropriate environment
variables, and set the encoding by
Marcin 'Qrczak' Kowalczyk wrote:
[Actually, regarding on-screen display, this is also an issue for
Unicode. How many people actually have all of the Unicode glyphs?
I certainly don't.]
If I don't have a particular character in fonts, I will not create
files with it in filenames.
Binary i/o is not specifically a Haskell problem. Other programming
systems, for example, Scheme, have been struggling with the same
issues. Scheme Binary I/O proposal may therefore be of some interest
in this group.
http://srfi.schemers.org/srfi-56/
It is deliberately made to be the
My thoughts on I/O, binary and chars can be summerised:
1) Produce a new WordN based IO library.
2) Character strings cannot be separated from their encodings
(ie they must be encoded somehow - even if that encoding
is ascii). I would approch this using parameterised phantom
I modestly re-propose the I/O model which I first proposed last year:
http://www.haskell.org/pipermail/haskell/2003-July/012312.html
http://www.haskell.org/pipermail/haskell/2003-July/012313.html
http://www.haskell.org/pipermail/haskell/2003-July/012350.html
On 15 September 2004 12:32, [EMAIL PROTECTED] wrote:
On Mon, Sep 13, 2004 at 12:01:58PM +0100, Glynn Clements wrote:
My view is that, right now, we have the worst of both worlds, and
taking a short step backwards (i.e. narrow the Char type and leave
the rest alone) is a lot simpler (and more
Simon Marlow [EMAIL PROTECTED] writes:
Here's a tarball that works with GHC 6.2.1 on a Unix platform, just
--make to build it:
http://www.haskell.org/~simonmar/new-io.tar.gz
Found a bug already...
In System/IO/Stream.hs, line 183:
streamReadBufrer s 0 buf = return 0
Henning Thielemann [EMAIL PROTECTED] writes:
I even plead for an abstract data type FilePath which supports
operations like 'enter a directory', 'go one level higher' and so
on.
Beware of Common Lisp history:
http://www.gigamonkeys.com/book/practical-a-portable-pathname-library.html
As we
Here is what happens when a language provides only narrow-char API for
filenames:
Start of forwarded message
Date: Wed, 15 Sep 2004 15:18:00 +0100
From: Peter Jolly [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
CC: caml-list [EMAIL PROTECTED]
Subject: Re:
Graham Klyne wrote:
In particular, the idea of narrowing the Char type really seems like a
bad idea to me (if I understand the intent correctly). Not so long ago, I
did a whole load of work on the HaXml parser so that, among other things,
it would support UTF-8 and UTF-16 Unicode (as
Henning Thielemann wrote:
Udo Stenzel wrote:
The same thoughts apply to filenames. Make them [Word8] and convert
explicitly. By the way, I think a path should be a list of names (that
is of type [[Word8]]) and the library would be concerned with putting in
the right path separator.
Marcin 'Qrczak' Kowalczyk wrote:
Here is what happens when a language provides only narrow-char API for
filenames:
I have a filename as an UTF-8 encoded string. I need to be able to
handle strange chars like accents, Asian chars etc.
Is there any way to create a file with that name?
Glynn Clements [EMAIL PROTECTED] writes:
The RTS doesn't know the encoding. Assuming that the data will use the
locale's encoding will be wrong too often.
If the program wants to get bytes, it should get bytes explicitly, not
some sort of pseudo-Unicode String.
Like so many other people,
19 matches
Mail list logo
