- Glasgow-haskell-users

How do I build GHC 7.6 from source?
by Iavor Diatchki 21 Sep '12

21 Sep '12

Hello, I was just trying to build the GHC-7.6 branch from source and the build failed with type-errors, because the libraries used by GHC have moved on since the release, and "sync all" just gets the most recent version. Is there a "fingerprint" somewhere so that I can checkout the libraries in a suitable form for building 7.6? More generally, I run into this problem all the time with people trying to build the branch I work on, so it really would be nice if we started using sub-modules to keep track of this dependency. I talked to folks at ICFP about this, and one idea was that we could check in the "fingerprint" for a branch into the repo, and track the dependencies this way, but this is exactly what git's submodule machinery does, so it seems pointless to implement the functionality which is already there with a standard interface. Thoughts? -Iavor

4 6

Why is Bag's Data instance "broken"?
by Philip Holzenspies 21 Sep '12

21 Sep '12

Dear GHCers, I'm performing traversals over GHC-API results (HsSyn et al). For this purpose, I'm using SYB generics. I found that I couldn't use "ext1Q" for a function with type "Data x => Bag x -> String", i.e. that this function was never applied. The source of Bag's instance of the Data class seems to explain why: instance Data a => Data (Bag a) where gfoldl k z b = z listToBag `k` bagToList b -- traverse abstract type abstractly toConstr _ = abstractConstr $ "Bag("++show (typeOf (undefined::a))++")" gunfold _ _ = error "gunfold" dataTypeOf _ = mkNoRepType "Bag" Is there a rationale to not allow gunfolds and to keep toConstr abstract? More to the point for my needs, is there a reason to not allow dataCast1 casting of Bags? Regards, Philip

3 8

Type operators in GHC
by Simon Peyton-Jones 19 Sep '12

19 Sep '12

Dear GHC users As part of beefing up the kind system, we plan to implement the "Type operators" proposal for Haskell Prime http://hackage.haskell.org/trac/haskell-prime/wiki/InfixTypeConstructors GHC has had type operators for some kind, so you can say data a :+: b = Left a | Right b but you can only do that for operators which start with ":". As part of the above wiki page you can see the proposal to broaden this to ALL operators, allowing data a + b = Left a | Right b Although this technically inconsistent the value page (as the wiki page discussed), I think the payoff is huge. (And "A foolish consistency is the hobgoblin of little minds", Emerson) This email is (a) to highlight the plan, and (b) to ask about flags. Our preferred approach is to *change* what -XTypeOperators does, to allow type operators that do not start with :. But that will mean that *some* (strange) programs will stop working. The only example I have seen in tc192 of GHC's test suite {-# LANGUAGE TypeOperators #-} comp :: Arrow (~>) => (b~>c, c~>d)~>(b~>d) comp = arr (uncurry (>>>)) Written more conventionally, the signature would look like comp :: Arrow arr => arr (arr b c, arr c d) (arr b d) comp = arr (uncurry (>>>)) or, in infix notation {-# LANGUAGE TypeOperators #-} comp :: Arrow arr => (b `arr` c, c `arr` d) `arr` (b `arr` d) comp = arr (uncurry (>>>)) But tc192 as it stands would become ILLEGAL, because (~>) would be a type *constructor* rather than (as now) a type *variable*. Of course it's easily fixed, as above, but still a breakage is a breakage. It would be possible to have two flags, so as to get - Haskell 98 behaviour - Current TypeOperator behaviuor - New TypeOperator behaviour but it turns out to be Quite Tiresome to do so, and I would much rather not. Can you live with that? http://chrisdone.com/posts/2010-10-07-haskelldb-and-typeoperator-madness.ht…

13 24

Kind Demotion
by Ashley Yakeley 18 Sep '12

18 Sep '12

Now that we have type promotion, where certain types can become kinds, I find myself wanting kind demotion, where kinds are also types. So for instance there would be a '*' type, and all types of kind * would be demoted to values of it. Is that feasible? -- Ashley Yakeley

2 4

ghc-mod and FFI
by Bernhard Urban 17 Sep '12

17 Sep '12

Hi, recently I run into an issue using ghc-mod, as described here: https://github.com/kazu-yamamoto/ghc-mod/issues/75 In summary, ghc-mod fails if the source file contains a `foreign' declaration. I played around a bit, but I have no experience with the GHC API, so any help is appreciated! Thanks, Bernhard

1 0

ghc 7.6.1 panic, http://hackage.haskell.org/trac/ghc/ticket/5252 not dead yet
by Evan Laforge 13 Sep '12

13 Sep '12

So I have something that looks similar to http://hackage.haskell.org/trac/ghc/ticket/5252, namely, given these two modules: % cat Midi.hs {-# OPTIONS_GHC -funbox-strict-fields #-} module Midi ( WriteMessage(..) , WriteDevice -- TODO due ghc bug: http://hackage.haskell.org/trac/ghc/ticket/5252 -- , WriteDevice(WriteDevice) ) where import qualified Data.ByteString as ByteString data WriteMessage = WriteMessage !WriteDevice newtype WriteDevice = WriteDevice ByteString.ByteString % cat CoreMidi.hs module CoreMidi where import qualified Midi write_message :: Midi.WriteMessage -> IO Bool write_message (Midi.WriteMessage _) = return True % ghc -c Midi.hs % ghc -c CoreMidi.hs ghc: panic! (the 'impossible' happened) (GHC version 7.6.1 for x86_64-apple-darwin): reboxProduct: not a product main:Midi.WriteDevice{tc r2M} Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Oddly, if I put {-# UNPACK #-} on the strict WriteDevice and remove -funbox-strict-fields, I don't get a crash anymore. Also, it has to be ByteString inside, I guess it has to do with the optimization ByteString applies. Shall I append to the old ticket, or create a new one?

1 0

recent changes to hsc2hs break wrapping c++
by Evan Laforge 09 Sep '12

09 Sep '12

Recently a change was made to hsc2hs to fix this ticket: http://hackage.haskell.org/trac/ghc/ticket/2897 Unfortunately, the result is I (apparently) can't use it now. Here's how that happens: The change was to remove the dependency on HsFFI.h. However, the solution is to create a little wrapper .c file that includes wrappers around various stdio functions like fputs(). This relies on C allowing implicit casts from void* to e.g. FILE*, and is also happy to let you use undeclared functions. g++ rejects that code. And since I am calling into C++ (via a 'extern "C" { ... }' wrapper) I wind up including C++ headers that contain the structs I want hsc2hs to calculate offsets for. Of course one solution is to use C as hsc2hs expects, but it would be awkward to split my (largish) c++ program's headers into C compatible and C++ only. So meanwhile I've reverted back to an older version of hsc2hs that includes HsFFI.h. Working with c++ headers was maybe not in the original design for hsc2hs, but it's a very useful feature nonetheless. WRT HsFFI.h and the ticket, I added -I(ghc --print-libdir)/include to my hsc2hs rule a long time ago, and it wasn't very hard to do, though I admit it would have been easier had there been documentation about what to do, or a mandatory flag for the HsFFI.h path. It looks like Duncan suggested that already. Or perhaps there's a better way to wrap C++?

3 6

Re: [Haskell] ANNOUNCE: GHC version 7.6.1
by Dennis Felsing 07 Sep '12

07 Sep '12

On 2012-09-07T09:00+1000, Ivan Lazar Miljenovic wrote: > > * It is now possible to defer type errors until runtime using the > > -fdefer-type-errors flag. > > Is this flag reversible in ghci, so I can :set it to check what's > going wrong with some code and then :unset it again? As you can see on http://www.haskell.org/ghc/docs/7.6.1/html/users_guide/flag-reference.html -fdefer-type-errors is dynamic, so you can reverse it using -fno-defer-type-errors.

1 0

Re: Holes in GHC
by Thijs Alkemade 05 Sep '12

05 Sep '12

Hi Simon and others, Yes, an update on our holes in GHC project was very due. What I've been working on: - The command line flag -XHoles and as a language pragma {-# LANGUAGE Holes #-} now work - Holes print a warning message with: - The origin of their type variables - Their local environment - Most of the code has been cleaned up to prepare it for submission as a patch. As an example of the message, consider the module: --- {-# LANGUAGE Holes #-} test x = foldr _ x _ --- This prints: --- [1 of 1] Compiling Main ( test2.hs, interpreted ) test2.hs:3:16: Warning: Found hole `_' with type a0 -> b -> b Where: `b' is a rigid type variable bound by the inferred type of test :: b -> b at test2.hs:3:1 `a0' is a free type variable In scope: x :: b test2.hs:3:20: Warning: Found hole `_' with type [a0] Where: `a0' is a free type variable In scope: x :: b Ok, modules loaded: Main --- The 3 currently remaining issues: - Free type variables are not tidied consistently. For every one of these hole warnings, the same TidyEnv is reused, without taking the updates from the other holes into account. I'm pretty sure I know where this happens and how I could fix it. - What I thought would be the local environment doesn't actually seem to be it. The holes store in their origin the result of `getLclTypeEnv' at their location, but as the Note [Bindings with closed types] says, the TopLevelFlag of these don't actually differentiate the top level from the non-top level bindings. I think it would be more helpful to only show the non-top level bindings at the hole's location, any hints about how to obtain just these would be appreciated. - The holes do not have very accurate source location information, like some other errors have. The hole has its origin, ("test2.hs:3:16"), but somehow not something like: "In the expression: folder _ x _, In an equation for `test': test x = foldr _ x _". Help with how that is supposed to work would also be appreciated. I'm attaching a patch of all my changes compared to HEAD as of about a week ago. All my work can also still be found on https://github.com/xnyhps/ghc. Best regards, Thijs Alkemade

4 4

Constraint error related to type family and higher-rank type
by Tsuyoshi Ito 05 Sep '12

05 Sep '12

Hello, Can anyone please explain why the following code is rejected by GHC (7.4.1)? The same code is also available at https://gist.github.com/3606849. ----- {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE FunctionalDependencies #-} {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE TypeFamilies #-} module Test1 where class C a b | b -> a data A = A data X = X data Y = Y type family TF b f :: (forall b. (C a b, TF b ~ Y) => b) -> X f _ = undefined u :: (C A b, TF b ~ Y) => b u = undefined v :: X v = f u -- This line causes an error (see below) ----- (1) GHC rejects this code with the following error message. Test1.hs:24:7: Could not deduce (C A b) arising from a use of `u' from the context (C a_c b, TF b ~ Y) bound by a type expected by the context: (C a_c b, TF b ~ Y) => b at Test1.hs:24:5-7 Possible fix: add (C A b) to the context of a type expected by the context: (C a_c b, TF b ~ Y) => b or add an instance declaration for (C A b) In the first argument of `f', namely `u' In the expression: f u In an equation for `v': v = f u (2) If I remove “TF b ~ Y” from the type of the argument of f and the type of u, then the code compiles. This suggests that the error message in (1) might not be the accurate description of the problem. (3) If I write “(f :: (forall b. (C A b, TF b ~ Y) => b) -> X)” instead of just “f” in the definition of v, then GHC reports a different error: Test1.hs:24:6: Cannot deal with a type function under a forall type: forall b. (C A b, TF b ~ Y) => b In the expression: f :: (forall b. (C A b, TF b ~ Y) => b) -> X In the expression: (f :: (forall b. (C A b, TF b ~ Y) => b) -> X) u In an equation for `v': v = (f :: (forall b. (C A b, TF b ~ Y) => b) -> X) u Item (3) might be related to a fixed Ticket #4310: http://hackage.haskell.org/trac/ghc/ticket/4310#comment:2 Best regards, Tsuyoshi

2 2