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
> assu
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 failu
On Thursday 16 September 2004 02:46 pm, Vincenzo aka Nick Name wrote:
> Again, I will try to take benefit of the thread on the "senior" list to
> ask a question to everybody who uses haskell in industry (so you people
> at Galois Connection can't avoid to answer, I know you are there :D ):
> are y
Again, I will try to take benefit of the thread on the "senior" list to
ask a question to everybody who uses haskell in industry (so you people
at Galois Connection can't avoid to answer, I know you are there :D ):
are your solutions entierely written in haskell, or are there parts
written in o
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 ju
Could anyone give me the MD5 sum of
http://www.haskell.org/ghc/dist/6.2.1/ghc-6-2-1_1.msi
I've been writing in Haskell for FreeBSD, and now I wanted to compile
one under windows. The .msi file seems to be broken, and I just wanted
to check...
--
DoubleF
"The more data I punch in this card, the
hello,
the types IO(IO ()) and IO() are not the same.
think of a value of type "IO a" as a _program_ that when executed
will return a result of type "a" (and while executing may print some
stuff to the screen).
now consider these types:
putStrLn :: String -> IO ()
this is a _pure function_ which
This should *not* display anything. Look at the types! displayFile1
returns a value that is the "displaying action". It does not "run"
it.
Replace "liftM" with "(=<<)" or use "join displayFile1" if you want to
run the displaying action.
mike
>> displayFile1 :: IO (IO ())
>> displayFi
At Thu, 16 Sep 2004 18:26:35 +0200,
[EMAIL PROTECTED] wrote:
>
>
> L.S.,
>
> In my enthusiasm to reduce imperative style coding to a minimum, I changed
> a program to something too lazy to do anything. The following is an
> extremely simplified version of the program:
>
> > import Monad
>
L.S.,
In my enthusiasm to reduce imperative style coding to a minimum, I changed
a program to something too lazy to do anything. The following is an
extremely simplified version of the program:
import Monad
displayFile1 :: IO (IO ())displayFile1 = liftM putStr contents --
Displays nothing
On Thu, 16 Sep 2004, Udo Stenzel wrote:
> Having a seperate byte based api is far better. If you don't know the
> encoding, all you have is bytes, no text.
Okay, after reading large chunks of this discussion, I'm going to rock the
boat a bit by suggesting that bytes *are* text, and *do* belong i
>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
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 both
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 ne
>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 th
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 argumen
On 16 September 2004 10:35, Glynn Clements wrote:
> 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
>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
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
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
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 propos
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
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 m
Marcin 'Qrczak' Kowalczyk wrote:
> >> When I switch my environment to UTF-8, which may happen in a few
> >> years, I will convert filenames to UTF-8 and set up mount options to
> >> translate vfat filenames to/from UTF-8 instead of to ISO-8859-2.
> >
> > But what about files which were been creat
Glynn Clements <[EMAIL PROTECTED]> writes:
> But this seems to be assuming a closed world. I.e. the only files
> which the program will ever see are those which were created by you,
> or by others who are compatible with your conventions.
Yes, unless you set the default encoding to Latin1.
>> So
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
[EMAIL PROTECTED] writes:
> The discussion of i18n i/o highlighted the need for general overlay
> streams. We should be able to place a processing layer onto a handle
> -- and to peel it off and place another one. The layers can do
> character encoding, subranging (limiting the stream to the speci
On Wed, 15 Sep 2004, Glynn Clements wrote:
> Henning Thielemann wrote:
>
> > I even plead for an abstract data type FilePath which supports operations
> > like 'enter a directory', 'go one level higher' and so on.
>
> Are you referring to "pure" operations on the FilePath, e.g. appending
> and
28 matches
Mail list logo
