October 2009 - Haskell-prime

Unsafe hGetContents
by Florian Weimer 23 Jan '10

23 Jan '10

Are there any plans to get rid of hGetContents and the semi-closed handle state for Haskell Prime? (I call hGetContents unsafe because it adds side effects to pattern matching, stricly speaking invalidating most of the transformations which are expected to be valid in a pure language.)

5 15

On support of C99 complex numbers
by Maurício CA 23 Oct '09

23 Oct '09

Hi, I would like to make a formal request for inclusion of complex numbers in Foreign.C.Types. Which steps should I follow? Here is a start on what I would write in such request. ----- Motivation: As complex is available in C, libraries can pass then by value in function calls, making it difficult to directly wrap such functions in Haskell. GNU GSL, for instance, even if actually using C < 99, does that with a struct type that is supposed to be binary equivalent to C99 double complex. Syntax: My sugestion is to add these: CFComplex --> for 'float complex' CDComplex --> for 'double complex' CLDComplex --> for 'long double complex' I believe this is better than trying to use a kind *->* type, as that would bring little help when actually wrapping C functions. Also, I think it's not important to have field names for real and imaginary, as long as we have an easy convertion for Data.Complex. Also, if we want to take imaginary and real parts in "pure C" Haskell code, we can use available C functions like cimag, creal, cimagf, crealf etc. ----- Thanks for your attention, Maurício

1 0

Unsafe hGetContents
by oleg＠okmij.org 20 Oct '09

20 Oct '09

Simon Marlow wrote: > Ah yes, if you have two lazy input streams both referring to the same > underlying stream, that is enough to demonstrate a problem. As for > whether Oleg's example is within the rules, it depends whether you > consider fdToHandle as "unsafe" I wasn't aware of the rules. Fortunately, UNIX (FreeBSD and Linux) give plenty of opportunities to shoot oneself. Here is the code from the earlier message without the offending fdToHandle: > {- Haskell98! -} > > module Main where > > import System.IO > > -- f1 and f2 are both pure functions, with the pure type. > -- Both compute the result of the subtraction e1 - e2. > -- The only difference between them is the sequence of > -- evaluating their arguments, e1 `seq` e2 vs. e2 `seq` e1 > -- For really pure functions, that difference should not be observable > > f1, f2:: Int ->Int ->Int > > f1 e1 e2 = e1 `seq` e2 `seq` e1 - e2 > f2 e1 e2 = e2 `seq` e1 `seq` e1 - e2 > > read_int s = read . head . words $ s > > main = do > let h1 = stdin > h2 <- openFile "/dev/stdin" ReadMode > s1 <- hGetContents h1 > s2 <- hGetContents h2 > -- print $ f1 (read_int s1) (read_int s2) > print $ f2 (read_int s1) (read_int s2) It exhibits the same behavior that was described in http://www.haskell.org/pipermail/haskell/2009-March/021064.html I think Windows may have something similar. > The reason it's hard is that to demonstrate a difference you have to get > the lazy I/O to commute with some other I/O, and GHC will never do that. The keyword here is GHC. I may well believe that GHC is able to divine programmer's true intent and so it always does the right thing. But writing in the language standard ``do what the version x.y.z of GHC does'' does not seem very appropriate, or helpful to other implementors. > Haskell's IO library is carefully designed to not run into this > problem on its own. It's normally not possible to get two Handles > with the same FD... Is this behavior is specified somewhere, or is this just an artifact of a particular GHC implementation?

6 9