- Haskell-Cafe - Haskell.org

Proofs for program testing
by Henning Thielemann 17 Sep '04

17 Sep '04

I saw that many introductions to Haskell contain proofs of properties of implemented functions. This is probably due to the fact that pure functions can be handled more easily than imperative programs with hidden states. I wondered whether one can use proofs of Haskell functions for testing. I found QuickCheck http://www.cs.chalmers.se/~rjmh/QuickCheck/ which, as far as I understand, relies on random inputs and I found http://homepages.inf.ed.ac.uk/wadler/realworld/era.html which sounds like some GUI driven program. Is there something that can be used for automatical testing, e.g. for darcs' tests to check patch integrity?

1 0

RE: [Haskell-cafe] Re: Writing binary files?
by MR K P SCHUPKE 17 Sep '04

17 Sep '04

>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.

2 1

RE: [Haskell-cafe] Re: Writing binary files?
by MR K P SCHUPKE 16 Sep '04

16 Sep '04

>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 than when reading in chunks you paste those chunks together before conversion, and you can only break outside of escapes. This in my opinion is better behaviour anyway... I don't want some hidden escape state mangling output, just because some earler code generated invalid output. Keean.

2 1

ghc-6-2-1_1.msi MD5 sum
by Sergey Zaharchenko 16 Sep '04

16 Sep '04

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 lighter it becomes, and the lower the mailing cost." -- Stan Kelly-Bootle, "The Devil's DP Dictionary"

1 0

Lifting makes lazy
by hjgtuyl＠chello.nl 16 Sep '04

16 Sep '04

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 > where > contents :: IO [Char] > contents = readFile "DisplayFile.lhs" This should display the contents of a file, but nothing appears. The following function should be exactly the same, but this one does display the file: > displayFile2 :: IO () > displayFile2 = do > contents <- readFile "DisplayFile.lhs" > putStr contents My conclusion is, that "putStr" is evaluated strictly, while "liftM putStr" is not. I have the following questions: - Why is this difference? - Is there some method to predict whether my program is sufficiently strict to really do what it is supposed to do? - Did someone design a method to develop programs not too strict and not too lazy? - The manual "A gentle introduction to Haskell" states in section 6.3: "adding strictness flags may lead to hard to find infinite loops or have other unexpected consequences"; I would like to know when these problems arise; are these cases described somewhere? -- Met vriendelijke groet, Herzliche Grüße, Best regards, Henk-Jan van Tuyl -------------------------------------------------------------------- Festina Lente Hasten Slowly Haast U langzaam Eile langsam Skynd dig langsomt Affrettati lentamente Spěchej pomalu Skynda långsamt Desiderius Erasmus --------------------------------------------------------------------

4 3

Re: [Haskell-cafe] Re: Writing binary files?
by Udo Stenzel 16 Sep '04

16 Sep '04

Glynn Clements <glynn.clements(a)virgin.net> 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 here? Making the breakage even worse by specifying a text based api that uses "no encoding"? Having a seperate byte based api is far better. If you don't know the encoding, all you have is bytes, no text. > Also, binary data and text aren't disjoint. Everything is binary; some > of it is *also* text. No, it isn't. Everything is binary (read: we need a byte based io library), after decoding and only after decoding it becomes text (read: we need explicit support for decoding and probably a convenience layer that looks like the old io library). > > String's are a list of unicode characters, [Word8] is a > > list of bytes. > > And what comes out of (and goes into) most core library functions is > the latter. So System.Directory needs to be specified in terms of bytes, too. Looks like a clean solution to me. Regards, Udo. ________________________________________________________________ Verschicken Sie romantische, coole und witzige Bilder per SMS! Jetzt neu bei WEB.DE FreeMail: http://freemail.web.de/?mc=021193

3 2

Re: [Haskell-cafe] Re: Writing binary files?
by MR K P SCHUPKE 16 Sep '04

16 Sep '04

>CommandLineToArgvW provides a way to obtain a Unicode Don't forget there are multiple encodings for unicode: UTF-8, UTF-16, UTF-32... Keean.

1 0

RE: [Haskell-cafe] Re: Writing binary files?
by Simon Marlow 16 Sep '04

16 Sep '04

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 of the issues. >> >> An easier way is just to declare that the existing API assumes a >> Latin-1 encoding consistently. Later we might add a way to let the >> application pick another encoding, or request that the I/O library >> uses the locale encoding. > > But how do you do that without breaking stuff? If the application > changes the encoding to UTF-8 (either explicitly, or by using the > locale's encoding when it happens to be UTF-8), then code such as: > > [filename] <- getArgs > openFile filename ReadMode > > will fail if filename isn't a valid UTF-8 sequence. Similarly for the > other cases where the OS accepts/returns byte strings but the Haskell > interface uses String. And that's the correct behaviour, isn't it? Actually I hadn't really considered filenames, I was just talking about data read & written via the IO library. > I'm less concerned about the handling of streams, as you can > reasonably add a way to change the encoding before any data has been > read or written. I'm more concerned about FilePaths, argv, the > environment etc. Yes, these are interesting issues. Filenames are stored as character strings on some OSs (eg. Windows) and byte strings on others. So the Haskell portable API should probably use String, and do decoding based on the locale (if the programmer asks for it). 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 bothered to dig through MSDN right now). I suspect these should be Strings in Haskell too, with appropriate decoding/encoding happening under the hood. Cheers, Simon

3 2

RE: [Haskell-cafe] Re: Writing binary files?
by MR K P SCHUPKE 16 Sep '04

16 Sep '04

>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 you could have read and write raw [Word8] and read and write char, somehting like: readWithEncoder :: ([Word8] -> [Char]) -> IO [Char] writeWithEncoder :: ([Char] -> [Word8]) -> [Char] -> IO () After all, how can you 'normalise' a filename to a standard encoding if you don't have a function to do so. Infact if you encounter a server with an encoding you have no converter for, you have no choice but to treat it as raw bytes? Keean.

2 1

RE: [Haskell-cafe] Re: Writing binary files?
by Simon Marlow 16 Sep '04

16 Sep '04

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 just to declare that the existing API assumes a Latin-1 encoding consistently. Later we might add a way to let the application pick another encoding, or request that the I/O library uses the locale encoding. Existing code continues to work, and there are no conceptual problems (a Char is still Unicode). You have to decide what happens when the programmer tries to output a Char that is out of range for Latin-1. The current behaviour is simply to take the code point mod 0x100, but we could also decide to raise an exception in this case. Cheers, Simon

2 1