- Glasgow-haskell-users

pseq strictness properties
by Duncan Coutts 21 Nov '08

21 Nov '08

I don't think I'm just speaking for myself when I say that pseq is confusing and the docs similarly. Given the type a -> b -> b we would assume that it is lazy in it's first arg and strict in the second. (Even in the presence of seq we know that it really really must be strict in it's second arg since it returns it or _|_ in which case it's still strict). Of course we know of the seq primitive with this type that is strict in both. However we also now have pseq that has the _opposite_ "static" strictness to the original expected strictness. Statically, pseq claims that it's strict in the first but lazy in the parameter that it _returns_. At runtime of course it is strict in both parameters. Given the need for pseq I would have expected pseq to statically be lazy in it's first argument (and actually be strict at runtime). I expected it'd statically be strict in the second arg. So I'm wondering if there is a good explanation for pseq having the opposite strictness properties to that which I expected. At first, even after reading the docs I assumed that it was just a typo and that it really meant it was lazy in the first arg (statically). I was just recording a patch to "fix" the documentation when I checked the underlying code and found to my surprise that the original docs are correct. I also think the docs need to be clarified to make this distinction between the actual strictness behaviour and what the compiler thinks it is during strictness analysis. Since they are different I think it's an important distinction to make. Now that I look at it, par has the same property, of statically being lazy in the second parameter that it returns (and thus is really strict). Again, this is not documented. Summary: why is it that way round, and can we think of a way to explain it better. Duncan

5 8

mmap() returned memory outside 2Gb - GHC on ubuntu hardy amd64
by Rahul Kapoor 21 Nov '08

21 Nov '08

I cannot get GHC to work on a fresh ubuntu hardy machine: On installing using the package manager I get an error when running ghci: "R_X86_64_32S relocation out of range:" - similar to http://hackage.haskell.org/trac/ghc/ticket/2013, but that bug is FreeBSD specific. I decided to install the binary distribution: after which running ghci fails with error: GHCi, version 6.10.1: http://www.haskell.org/ghc/ :? for help ghc: internal error: mmap() returned memory outside 2Gb (GHC version 6.10.1 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Aborted I Added issues #2779 to Trac for the second case. Are there any possible work arounds for these problems? Rahul

3 13

GHC 6.10.1 type puzzler
by Dave Bayer 19 Nov '08

19 Nov '08

Here is an example illustrating a type problem I've having with GHC 6.10.1: > module Main where > > newtype Box a = B a > > make :: a -> Box a > make x = B x > > val :: Box a -> a > val (B x) = x > > test1 :: Box a -> a -> [a] > test1 box x = go box x > where > go :: Box a -> a -> [a] > go b y = [(val b), y] > > test2 :: Box a -> a -> [a] > test2 box x = go x > where > -- go :: a -> [a] > go y = [(val box), y] > > main :: IO () > main = do > print $ test1 (make 1) 2 If I uncomment the commented type declaration, I get the familiar error > Couldn't match expected type `a1' against inferred type `a' On the other hand, the earlier code is identical except that it passes an extra argument, and GHC matches the types without complaint. This is a toy example to isolate the issue; in the actual code one wants a machine-checkable type declaration to help understand the function, which is local to save passing an argument. To the best of my understanding, I've given the correct type, but GHC won't make the inference to unify the type variables. I wonder if I found a GHC blind spot. However, it is far more likely that my understanding is faulty here. Any thoughts? Thanks, Dave

4 4

language features in 6.10.1
by Serge D. Mechveliani 19 Nov '08

19 Nov '08

The GHC team writes > The (Interactive) Glasgow Haskell Compiler -- version 6.10.1 > [..] > There have been a number of significant changes since the last > major release, including: > > * Some new language features have been implemented: > * Record syntax: wild-card patterns, punning, and field disambiguation > * Generalised quasi-quotes > * Generalised list comprehensions > * View patterns > > [..] Please, where and in what chapters these 4 language features are documented? Thank you in advance for help, ----------------- Serge Mechveliani mechvel(a)botik.ru

2 1

Re: Unicode's greek lambda
by Donn Cave 18 Nov '08

18 Nov '08

Quoth Duncan Coutts <duncan.coutts(a)worc.ox.ac.uk>: | On Tue, 2008-11-18 at 11:51 +0000, Ross Paterson wrote: |> But it could be a reserved word synonymous with \. After all, \ can |> occur in operator symbols, but the operator \ is reserved. | | Presumably that would let you do (\ x -> ...) but not (\x -> ) since the | "\x" would run together and lexically it would be one identifier. Good, that's clearly the right way to do it anyway! Donn

1 0

6.10.1 Bug?
by Dominic Steinitz 18 Nov '08

18 Nov '08

According to the hackage page, the Haskell Cryptography Library has a build failure. I couldn't find a bug reference when I searched for milestone 6.10.1 on trac. Should I report it? Has it been fixed? Thanks, Dominic. http://hackage.haskell.org/packages/archive/Crypto/4.1.0/logs/failure/ghc-6… > [4 of 4] Compiling Main ( SHA1Test.hs, dist/build/SHA1Test/SHA1Test-tmp/Main.o ) > ghc: panic! (the 'impossible' happened) > (GHC version 6.10.1 for i386-unknown-linux): > RegAllocLinear.getStackSlotFor: out of stack slots, try -fregs-graph > > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug

3 3

Cannot escape from a black hole in ghci 6.10.1
by Ahn, Ki Yung 18 Nov '08

18 Nov '08

Dear GHC users I have both GHC 6.8.2 (debian unstable package) and GHC 6.8.10 (binary distribution from ghc homepage) installed. I was able to escape from a black hole in ghci 6.8.2 with Ctrl-C. For example, GHCi, version 6.8.2: http://www.haskell.org/ghc/ :? for help Loading package base ... linking ... done. Prelude> let x = x + x Prelude> x ^CInterrupted. Prelude> x *** Exception: stack overflow Prelude> Interestingly, you will get a stack overflow when you try to escape from the black home for the second time. In ghci 6.10.1, I am not able to escape from a black hole with Ctrl-C. GHCi, version 6.10.1: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer ... linking ... done. Loading package base ... linking ... done. Prelude> let x = x + x Prelude> x ^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C ... (doesn't work) You can't escape from the black hole and ghci will start eating up your memory unless kill the ghci process. Now the black hole behaves like a real black hole :-) Is this a ticketed bug, or should we make a new ticket? -- Ahn, Ki Yung

2 1

Trouble with ghc on linux x86_64
by Bit Connor 18 Nov '08

18 Nov '08

The system is a xen virtual machine: Linux 2.6.24-19 SMP x86_64 Dual-Core AMD Opteron(tm) Processor 2212 AuthenticAMD GNU/Linux With GHC version 6.8.2, ghci gives the error: $ ghci GHCi, version 6.8.2: http://www.haskell.org/ghc/ :? for help ghc-6.8.2: internal error: R_X86_64_32S relocation out of range: (noname) = 0x7f10a29e56d0 (GHC version 6.8.2 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Aborted GHC version 6.10.1 gives a similar error: $ ghci GHCi, version 6.10.1: http://www.haskell.org/ghc/ :? for help ghc: internal error: mmap() returned memory outside 2Gb (GHC version 6.10.1 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Aborted These same 2 results happen on 2 different distros that I've tried. With both GHC versions, compiling haskell programs sometimes works, but sometimes hangs during the linking stage. The results are the same using the distro provided packages and with the binaries from the ghc website. I also actually managed to compile ghc version 6.10.1 using ghc 6.8.2, but not completely, "make" got froze during haddock generation for ghc-6.10.1. There was however a "ghc" binary that was produced in the directory ghc/dist-stage2/build/ghc/ghc. Running this binary as --interactive gave the exact same 6.10.1 error above. Any ideas? Thanks, Bit

2 3

problem with echo prompting in ghci (visible in emacs)
by Conal Elliott 17 Nov '08

17 Nov '08

ghci echoes all of my input in emacs, when run via haskell-mode or via "M-x shell", which then confuses various useful haskell-mode features. I built it from sources. At the time I didn't have libedit-dev, so today I installed libedit-dev (version 2.11~20080614 on ubuntu), did a clean make & install, and I get exactly the same behavior. Does anyone have experience in getting through this problem? Willing to help me out? Thanks, - Conal

2 3

more libedit.so.0 issues
by James Swaine 17 Nov '08

17 Nov '08

We've had unbelievable problems getting past this ridiculous 'unable to load object file or shared library libedit.so.0' error when attempting to build the 6.10.1 source tree. We initially just built editline in a user directory and attempted to manipulate environment variables to help the linker (e.g. setting LIBRARY_PATH, LD_LIBRARY_PATH, and CPATH) - but this did no good. We then just installed the editline package so it's available globally and the libraries (specifically libedit.so.0) live in /usr/local/lib, so it should be found with no problem. Not so for ghc - same error. We're running this on Red Hat. I'm part of a research group at Northwestern University that is exploring the use of ghc and associated libraries for some upcoming projects. It's a shame that this is so difficult to even compile/install, and nobody seems to be able to figure out what's wrong.

6 13