October 2007 - Glasgow-haskell-users

partially applied type synonyms
by Arie Peterson 05 Mar '12

05 Mar '12

Dear list, Is there a good reason that partially applied type synonyms cannot be made instances of classes? - A simple example would be making the identity type 'Id' ("type Id x = x") instance of 'Monad'. This would eliminate the need for some silly occurrences of 'runIdentity', and perhaps narrow the gap between monads and monad transformers. - The reason I complain about this now is a more involved example, where introducing a newtype to work around the restriction is not an option. Well, not as far as I can see now, anyway. Partially applied type synonyms are, in a sense, the anonymous functions at the type level, and one might argue that they deserve the same 'first-class member status' as the lambda at the value level. Kind regards, Arie Peterson

3 2

ghci and ghc -threaded broken with pipes & forking
by John Goerzen 29 Dec '08

29 Dec '08

Hi, I've been hitting my head against a wall for the past couple of days trying to figure out why my shell-like pipeline code kept hanging. I found fd leakage (file descriptors not being closed), which disrupts EOF detection and can lead to deadlocks. I just couldn't find the problem. I finally tried compiling my test with ghc instead of running it in ghci. And poof, it worked fine the first time. I tried asking on #haskell, and got the suggestion that ghci uses -threaded. I tried compiling my test program with ghc -threaded, and again, same deadlock. My program never calls forkIO or forkOS or any other threading code. You can see my test case with: darcs get '--tag=glasgow ml' http://darcs.complete.org/hsh ghc -fglasgow-exts --make -o test2 test2.hs That'll run fine. If you add -threaded, it will hang. Ideas? Thanks, -- John

13 44

Why only inference in type checking?
by Philip K.F. Hölzenspies 07 Nov '07

07 Nov '07

Dear All, A while ago, I had trouble understanding the coverage condition and I raised a question on this mailing list. Help was swift and adequate, especially the reference to the paper entitled "Understanding Functional Dependencies via Constraint Handling Rules" was very useful. However, having considered the problem of non-termination of the type checker, I can't help but wonder why the type checker is "inference only." From the paper mentioned above, consider the following example: class Mul a b c | a b -> c where (*) :: a -> b -> c type Vec b = [b] instance Mul a b c => Mul a (Vec b) (Vec c) where ... f b x y = if b then (*) x [y] else y For actual arguments of f, there is no issue whatsoever with decidability. The type checker in my brain uses unification, i.e. top-down. The type checker in GHC uses inference, i.e. bottom-up. Why inference potentially suffers from non-termination for this program, I understand. My question is this: Is there a reason why type checking in GHC is inference-only, as opposed to a meet-in-the-middle combination of unification and inference? Would the type checker use both unification and inference (let's say alternating evaluation of both), the number of programs for which termination can be guaranteed is considerably larger - if I'm not mistaken, but I may very well have gotten it wrong. Regards, Philip PS. I realize that for this dependent typing scenario is useless once Type Families are here. I can't wait for a GHC with TFs. I raise this question, simply to understand why inference was chosen exclusively.

2 3

Too many local registers...
by Cristian Perfumo 03 Nov '07

03 Nov '07

Hi, I did some modifications to GHC in order to read hardware counters. Many programs are compiled successfully, but with one of them, I have a problem: Too many local registers allocated by gcc at .../ghc-6.6.1-modified/driver/mangler/ghc-asm line 1602, <INASM> line 304643. It's ghc 6.6.1 on an Itanium processor. Some suggestion? Thanks in advance for an answer. Cristian

4 4

confusing GADT/scoped type variables behaviour
by Ganesh Sittampalam 02 Nov '07

02 Nov '07

Hi, I'm having some trouble writing code that uses GADTs. I finally got something that is portable between GHC 6.6 and 6.8, but I don't really understand what's going on, and I'm a bit unhappy with the number of type signatures required. I'll explain them with a series of cut-down examples below, so please forgive the gratuitous beta-redexes. My testing has been with GHC 6.6 and 6.8.0.20070921, but I believe from more limited testing that 6.6.1 behaves the same as 6.6. My first program works fine with both GHC 6.6 and 6.8: {-# OPTIONS_GHC -fglasgow-exts #-} module GADT where data C x y where C :: P x y -> C x x data P x y where P :: Q x y -> P x y data Q x y where Q :: Q x y data D x y where D :: C y z -> D x z f :: forall x y . D x y -> () f (D (C p)) | P q <- (\p -> p) p = case q of Q -> () {- end of program -} However, when I change it slightly to make the lambda expression inspect the structure of p: {-# OPTIONS_GHC -fglasgow-exts #-} module GADT where data C x y where C :: P x y -> C x x data P x y where P :: Q x y -> P x y data Q x y where Q :: Q x y data D x y where D :: C y z -> D x z f :: forall x y . D x y -> () f (D (C p)) | P q <- (\p@(P a) -> p) p = case q of Q -> () {- end of program -} it continues to work with 6.6, but 6.8 complains that q has a wobbly type and I should add a type annotation. So, I do so, also adding one to the original pattern for p otherwise my type variables aren't in scope: {-# OPTIONS_GHC -fglasgow-exts #-} module GADT where data C x y where C :: P x y -> C x x data P x y where P :: Q x y -> P x y data Q x y where Q :: Q x y data D x y where D :: C y z -> D x z f :: forall x y . D x y -> () f (D (C (p :: P w z))) | P q :: P w z <- (\p@(P a) -> p) p = case q of Q -> () {- end of program -} Fine with 6.8, but now 6.6 is unhappy. The type variable 'w' is actually the same as 'y', and 6.6 seems to have noticed this fact and says I should have given them the same name. So, I do so: {-# OPTIONS_GHC -fglasgow-exts #-} module GADT where data C x y where C :: P x y -> C x x data P x y where P :: Q x y -> P x y data Q x y where Q :: Q x y data D x y where D :: C y z -> D x z f :: forall x y . D x y -> () f (D (C (p :: P y z))) | P q :: P y z <- (\p@(P a) -> p) p = case q of Q -> () {- end of program -} Now 6.6 is happy. But 6.8 doesn't believe they are the same, and rejects it. I finally got it to work with both by removing the forall in the signature of f: {-# OPTIONS_GHC -fglasgow-exts #-} module GADT where data C x y where C :: P x y -> C x x data P x y where P :: Q x y -> P x y data Q x y where Q :: Q x y data D x y where D :: C y z -> D x z f :: D x y -> () f (D (C (p :: P y z))) | P q :: P y z <- (\p@(P a) -> p) p = case q of Q -> () {- end of program -} But, I don't really understand why this is so. I guess the 'y' in the outer signature is no longer a scoped type variable, so 6.6 doesn't complain, and is no longer the same as the inner 'y', so 6.8 doesn't complain, but it all feels a bit unsatisfactory. So, is there a good explanation of the errors from 6.8? Is 6.8 behaving as expected? Finally, ideally I'd like not to have any type signatures in the body of f - is this feasible with 6.8 like it was with 6.6? Cheers, Ganesh

3 2

Case of "Language" pragma - bug?
by Robin Bate Boerop 02 Nov '07

02 Nov '07

I'm using GHC 6.6.1. The manual says: "Pragmas all take the form {-# word ... #-} where word indicates the type of pragma, and is followed optionally by information specific to that type of pragma. Case is ignored in word." However, when I use "Language CPP" instead of "LANGUAGE CPP" in the pragma, the pragma is ignored. Is this a documentation bug? To test the problem, one can use "ghc --make testpragma1.hs" and "ghc --make testpragma2.hs" on the following: -- Robin Bate Boerop

7 7

Incompatibility between Yi and GHC 6.8 (rc)
by Jean-Philippe Bernardy 25 Oct '07

25 Oct '07

Hello, I spent some time to make Yi work with 6.8, and failed up to now. Before I go into details, let's see what I'm trying to do with Yi. The idea is to have a fully dynamic application where the user is allowed to run arbitrary haskell code on the command line. This can be used to quickly test new code, etc. In particular, one needs to be able to "reload" the configuration in that manner. This is achieved basically by having everything running inside a specially made "GHC Session". The dynamic code is able to "reload itself" because it is passed a pointer to the GHC session. The GHC experts will see here that this cannot work :) Indeed, GHC has a number of "global variables", which, if accessed through code loaded in a GHC session, will be instanciated again. This means that accessing a "level 1" session with "level 2" code is normally not possible. However, I found a workaround: encapsulate all calls to the GHC API in a data structure in "level 1" code, which is then passed to "level 2". (A haskell version of C-style callbacks). While this worked beautifully with GHC 6.6, it fails with 6.8rc. with exception :: GhcException yi: panic! (the 'impossible' happened) (GHC version 6.8.0.20071019 for i386-unknown-linux): a static opt was looked at too early! This happens at a seemingly unrelated point in the code. (inside the bytecode interpreter?) I can't really report a bug here, because what I'm trying to do is probably fairly unsupported by GHC. However, I'd appreciate some sort of advice. Is my workaround the correct approach? How would GHC people implement a dynamic application? Should I drop the idea completely? ... Thanks in advance for your help :) -- JP Attached: a darcs patch to the Yi repo to (try to) support 6.8.

1 0

ANNOUNCE: GHC 6.8.1 Second Release Candidate
by Ian Lynagh 25 Oct '07

25 Oct '07

We are pleased to announce the Second Release Candidate phase for GHC 6.8.1. The 6.8.1 release is very close now. We only intend to look at the bugs listed here: http://hackage.haskell.org/trac/ghc/query?status=new&status=assigned&status… so if you think there is something important that is not listed there then this is the time to shout! You can get 6.8.1 snapshots to test from here: http://www.haskell.org/ghc/dist/stable/dist/ Right now we have the source bundles: http://www.haskell.org/ghc/dist/stable/dist/ghc-6.8.0.20071015-src.tar.bz2 http://www.haskell.org/ghc/dist/stable/dist/ghc-6.8.0.20071015-src-extralib… Only the first of these is necessary. The "extralibs" package contains various extra packages that are sometimes supplied with GHC - unpack the extralibs tarball on top of the source tree to add them, they will be included in the build automatically. There are also binary distributions for x86_64/Linux and i386/Linux, and an installer for Windows. Please test as much as possible, bugs are much cheaper if we find them before the release! We expect to release later this month. Thanks Ian, on behalf of the GHC team

6 10

kind error
by Brammert Ottens 24 Oct '07

24 Oct '07

Hello, I am trying to recompile some haskell code. I have previously compiled it with ghc 6.4 and that went fine. The lines that give the trouble are import qualified Data.Edison.Coll.UnbalancedSet as US import qualified Data.Edison.Coll.MinHeap as MH data DecoratedFormula = DF{formula :: Formula, iformula :: IFormula} type FastClause = MH.Min US.Set DecoratedFormula When compiling with ghc 6.6.1 and edison 1.2.1 I get the following error message: FastClause.hs:71:25: `US.Set' is not applied to enough type arguments Expected kind `*', but `US.Set' has kind `* -> *' In the type synonym declaration for `FastClause' I have no idea how to solve this error, since as far as I can see the type declarations of both MinHeap and Set do not seem to have changed. Any suggestions are more then welcome. Regards, Brammert

3 3

type families not advertised for 6.8
by Wolfgang Jeltsch 24 Oct '07

24 Oct '07

Hello, on <http://hackage.haskell.org/trac/ghc/ticket/1716#comment:2> I read: “we are not advertising type equalities for 6.8”. What does this mean? Is it possible that type family support will be removed from GHC at some point? Best wishes, Wolfgang

5 14