2.02: error checking bug.
The following erroneous fragment erroneously compiles. data Token = TokNewline
Minor minor bug (tlist) in ghc-2.01 leads to panic...
Hallo Haskell-Hackers, I'm still using the old ghc-2.01. In one program I ran into a problem I couldn't fix. But I played around with it, I found a small little script which reproduces it very well: type state = ([Int] Bool) Okay, okay it's very pathological. Really maleficent :-) But imagine there were much more entries in this type statement, it spans over several lines, and comments all around it... There are always situations where you enter such little typos and afterwards you wonder why the compiler gets mad :-) Below a longer bug report! Thanks for listening! And stop laughing :-) Ciao, Wolfgang drotschm@euros--3- /home/III/stud/drotschm/FuPro/Haskell/ghc-2.01/bin/ghc-2.01 -c -v -fhaskell-1.3 -i.:/home/III/stud/drotschm/FuPro/Haskell/ghc-2.01/lib/ghc/2.01/imports f.lhs -o f.o The Glorious Glasgow Haskell Compilation System, version 2.01 patchlevel 0 literate pre-processor: echo '#line 1 "f.lhs"' /tmp/ghc16412.lpp /home/III/stud/drotschm/FuPro/Haskell/ghc-2.01/lib/ghc/2.01/sparc-sun-solaris2/unlit f.lhs - /tmp/ghc16412.lpp real0.1 user0.0 sys 0.0 Ineffective C pre-processor: echo '#line 1 "f.lhs"' /tmp/ghc16412.cpp cat /tmp/ghc16412.lpp /tmp/ghc16412.cpp real0.0 user0.0 sys 0.0 Haskell compiler: /home/III/stud/drotschm/FuPro/Haskell/ghc-2.01/lib/ghc/2.01/sparc-sun-solaris2/hsc ,-W ,/tmp/ghc16412.cpp -fignore-interface-pragmas -fomit-interface-pragmas -fsimplify \( -ffloat-lets-exposing-whnf -ffloat-primops-ok -fcase-of-case -freuse-con -fpedantic-bottoms -fsimpl-uf-use-threshold0 -fessential-unfoldings-only -fmax-simplifier-iterations4 \) -himap=/tmp/ghc16412.himap -v -hifile=/tmp/ghc16412.hi -S=/tmp/ghc16412.s +RTS -H600 -K100 Glasgow Haskell Compiler, version 2.01, for Haskell 1.3 panic! (the `impossible' happened): tlist Please report it as a compiler bug to [EMAIL PROTECTED] real4.3 user0.0 sys 0.2 deleting... /tmp/ghc16412.hi /tmp/ghc16412.s rm -f /tmp/ghc16412* drotschm@euros--4-
Bug in Concurrent Haskell
There's a bug in the signalQSemN function in the Semaphore module. (In versions ghc-0.29 through 2.03). The following function blocks when x=y, but works when y=x-1. f x y = do qSem - newQSemN 0 forkIO (waitQSemN qSem y) threadDelay 1000 signalQSemN qSem x return () The signalQSemN function needs a 1 line fix, included below. Cheers, Meurig *** Semaphore.lhs.bug signalQSemN :: QSemN - Int - IO () signalQSemN (QSemN sem) n = takeMVar sem = \ (avail,blocked) - free (avail+n) blocked= \ (avail',blocked') - putMVar sem (avail',blocked') return () where free avail [] = return (avail,[]) free avail ((req,block):blocked) = ! if avail req then putMVar block () free (avail-req) blocked else free avail blocked = \ (avail',blocked') - return (avail',(req,block):blocked') *** Semaphore.lhs signalQSemN :: QSemN - Int - IO () signalQSemN (QSemN sem) n = takeMVar sem = \ (avail,blocked) - free (avail+n) blocked= \ (avail',blocked') - putMVar sem (avail',blocked') return () where free avail [] = return (avail,[]) free avail ((req,block):blocked) = ! if avail = req then putMVar block () free (avail-req) blocked else free avail blocked = \ (avail',blocked') - return (avail',(req,block):blocked')
Re: Minor minor bug (tlist) in ghc-2.01 leads to panic...
| I couldn't fix. But I played around with it, I found a small little | script which reproduces it very well: | | type state = ([Int] Bool) ... | panic! (the `impossible' happened): | tlist This bit me some while ago, so don't be embarassed about writing an incorrect program! Anyway, I fixed it, so it's ok in 2.02 onwards, I believe. Simon
Re: Pattern guards
| f c | (i,j) - Just (toRect c) = ... | | I'm afraid this example suffers from the same problem as my "simplify" | example did: It does not perform a test and can thus be replaced by | | f c = ... | where (i,j) = toRect c True. I can think of two non-contrived ways in which this would not work so well. First, "c" might be got from another pattern match: f d | Just c - h d, (i,j) - toRect c = ... Then you couldn't use a where clause. Second, the view might often be the maybe-like kind: data SnocView a = Snoc [a] a | SNil snocView :: [a] - SnocView a f xs | Snoc ys y - snocView xs = ... You could instead give snocView the type snocView :: [a] - Maybe ([a], a) but I find that less appealing somehow. But as we keep saying, you certainly can code up everything in terms of everything else. Simon
Re: 2.02: error checking bug.
Here's a much simpler instance of my previous bug report: data A = T | T is missed by ghc-2.02 error-checking, but caught in 2.03. Problem solved in advance, then, really. Alex.
status of the powerpc port of ghc ?
Hi! I have ported GUM from PVM to MPI and would like to make some runtime tests on IBM SP2. Therefore, I started working on a rs6000 port of ghc. I just realized that someone else is working on a powerpc port of ghc: in the 2.03 version there is a new mangle_asm routine for powerpc and the powerpc part in COptJumps was changed as well. Are you currently working on the rest of the changes? When do you plan to have it all done? I made the changes in COptJumps and COptWraps and ended up with a version which could not be linked. I guess I need to split the object files. Did you already write the splitting routine? Thanks, Mari Pl|macher
Re: pattern guards + monads
I am having a little trouble following the two discussions on pattern guards and monads, due to some (probably minor) confusing pieces of syntax. Would anyone like to clarify these for me? It would help me to understand the underlying issues. Thanks. On pattern guards, Simon PJ writes: f (x:xs) | x0 = e1 | x0 = e2 | otherwise = e3 then g a | (x:xs) - h a, x0 = e1 | (x:xs) - h a, x0 = e1 | otherwise = e3 Am i right in thinking that f [] is bottom, whilst g [] is e3? Later, another definition of g (intended to be equivalent?) is given in which g [] appears to be bottom: g a | (x:xs) - h a | x0 = e1 | x0 = e2 | otherwise = e3 To match the semantics of the earlier definition of g, shouldn't this read as follows? g a | (x:xs) - h a | x0 = e1 | x0 = e2 | otherwise = e3 Now, for monads, Phil Wadler writes a law: m = \x - k x ++ h x = m = k ++ n = k in which 'h' appears on the lhs but not the rhs, and 'n' on the rhs but not the lhs. Are h and n the same? Or perhaps the equation should read as follows? m = \x - k x ++ h x = m = k ++ m = h Regards, Malcolm [EMAIL PROTECTED]
Re: pattern guards + monads
Now, for monads, Phil Wadler writes a law: m = \x - k x ++ h x = m = k ++ n = k in which 'h' appears on the lhs but not the rhs, and 'n' on the rhs but not the lhs. ... perhaps the equation should read as follows? m = \x - k x ++ h x = m = k ++ m = h Yes, of course it should. Thanks for the correction. -- P
