September 2012 - Glasgow-haskell-users

ghc api and .o files
by Evan Laforge 25 Sep '12

25 Sep '12

I'm using the GHC api to run a little REPL for my app. This involves linking in some compiled C, and as long as it's in a library it's fine, I just pass -lwhatever to parseDynamicFlags and it's happy. However, I also have a plain .o file, and from poking at the ghci source, it looks like that works by consing onto v_Ld, which is not exported from StaticFlags. I was just about to go verify this, but it looks like it just changed! So maybe .o files can now be passed to parseStaticFlags? Or even better, parseDynamicFlags? However, it seems to have happened very recently, and 7.6.1 is still using the v_Ld global. Does this mean that there's no way to link in an arbitrary .o? I suppose I can work around it by packing the .o into a libx.a and then passing -lx. Relatedly, I've noticed that OS X is forgiving when you don't link in a needed object. It will let me run code, but if I call a function that's not linked in I get a crash. However, linux immediately prints "unknown symbol `etc.'". The OS X behaviour is more convenient because it's easy to avoid calling the missing functions, and difficult to figure out how to cut all the dependencies so they're not needed, but the linux way is certainly safer. Does anyone know why this difference exists? Just curious. As an aside, I recently upgraded to 7.6.1 from 7.0.3 and the API changed in a numer of ways. Is there any documentation for those changes? I'm guessing not, since there's not much documentation for the API itself, except of course the code. I noticed that GHC.getWarnings disappeared, and seems to have been replaced with either printing directly to stderr or throwing an exception, e.g. HscTypes.handleFlagWarnings. Other than the expected hassles from depending on an internal API, 7.6.1 has been great so far, except of course hackage had to go down as soon as it was time to cabal install everything. thanks!

3 5

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 06 Sep '12

06 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