You wouldn't want to have to accumulate the
entire body as a single byte string
Ever heard of lazyness? Haskell does it quite well... Accumulating
the entire body doesn't really do this because haskell is lazy. You
don't need a more complex interface in Haskell!
Keean.
MR K P SCHUPKE wrote:
You wouldn't want to have to accumulate the
entire body as a single byte string
Ever heard of lazyness? Haskell does it quite well... Accumulating
the entire body doesn't really do this because haskell is lazy. You
don't need a more complex interface in Haskell!
Are
Gabriel Ebner wrote:
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 itself?
Gabriel Ebner wrote:
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.
Er, that's what I've been saying. And most
On 16 September 2004 00:02, Glynn Clements wrote:
Which is why I'm suggesting changing Char to be a byte, so that we can
have the basic, robust API now and wait for the more advanced API,
rather than having to wait for a usable API while people sort out all
of the issues.
An easier way is
Glynn Clements [EMAIL PROTECTED] schrieb am 16.09.04 10:46:58:
Gabriel Ebner wrote:
One more reason to fix the I/O functions to handle encodings and have
a seperate/underlying binary I/O API.
The problem is that we also need to fix them to handle *no encoding*.
What are you proposing
Simon Marlow wrote:
Which is why I'm suggesting changing Char to be a byte, so that we can
have the basic, robust API now and wait for the more advanced API,
rather than having to wait for a usable API while people sort out all
of the issues.
An easier way is just to declare that the
Udo Stenzel wrote:
One more reason to fix the I/O functions to handle encodings and have
a seperate/underlying binary I/O API.
The problem is that we also need to fix them to handle *no encoding*.
What are you proposing here? Making the breakage even worse by specifying
a text
E.g. what happens if you call getDirectoryContents for a directory
which contains filenames which aren't valid in the current encoding?
Surely this shows the problem with the idea of a 'current encoding'
... You could be reading files from two remote servers each using
different encodings...
So
MR K P SCHUPKE wrote:
E.g. what happens if you call getDirectoryContents for a directory
which contains filenames which aren't valid in the current encoding?
Surely this shows the problem with the idea of a 'current encoding'
Yes.
In case I haven't already made this clear, my argument is
In the general case, it needs to be a bit more complex than that,
Thats why the functions handled lists not individual characters,
I was assuming that each [Word8] - [Char] represented a valid
and complete encoding block... IE at the start of each call it
assumes no escapes. All this means is
Glynn Clements [EMAIL PROTECTED] writes:
If you want text, well, tough; what comes out most system calls and
core library functions (not just read()) are bytes.
Which need to be interpreted by the program depending on where these
bytes come from.
They don't necessarily need to be
On 2004 September 16 Thursday 06:19, Simon Marlow wrote:
Argv and the environment - I don't know. Windows CreateProcess() allows
these to be UTF-16 strings, but I don't know what encoding/decoding
happens between CreateProcess() and what the target process sees in its
argv[] (can't be
CommandLineToArgvW provides a way to obtain a Unicode
Don't forget there are multiple encodings for unicode:
UTF-8, UTF-16, UTF-32...
Keean.
___
Haskell-Cafe mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Simon Marlow wrote:
Which is why I'm suggesting changing Char to be a byte, so that we
can have the basic, robust API now and wait for the more advanced
API, rather than having to wait for a usable API while people sort
out all of the issues.
An easier way is just to declare that
Gabriel Ebner wrote:
For case testing, locale-dependent sorting and the like, you need to
convert to characters. [Although possibly only temporarily; you can
sort a list of byte strings based upon their corresponding character
strings using sortBy. This means that a decoding failure only
MR K P SCHUPKE wrote:
In the general case, it needs to be a bit more complex than that,
Thats why the functions handled lists not individual characters,
I was assuming that each [Word8] - [Char] represented a valid
and complete encoding block... IE at the start of each call it
assumes no
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
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
