July 2014 - Glasgow-haskell-users

GhcPlugin-writing and "finding things"
by p.k.f.holzenspies＠utwente.nl 25 Jul '14

25 Jul '14

Dear GHC-ers, I'm working on a plugin for GHC that should help compile the library with which this plugin is to ship. What this plugin does is traverse the CoreProgram(s) to find things of types defined in my library and optimizes them. I have worked out how to "find" things, but I was wondering whether the API could be improved for plugin-writers. For the sake of argument, I have the following: - module Foo: library for users to import, containing functions, ADTs etc - module Foo.Plugin: GhcPlugin that compiles out all uses of things in Foo > module Foo where > > data Foo x = Foo x > > runFoo :: Foo x -> x > runFoo (Foo x) = x This example is trivial and I imagine GHC will have no trouble eliminating most cases of this, but imagine more complex stuff. Now, if I want to traverse the CoreProgram in my plugin, I need to find occurrences of these, so somewhere there's stuff like: > pass tcFoo _ _ (NonRec b expr) > | varType b `containsTyConAnywhere` tcFoo > = {- clever stuff to compile out Foo -} My problem is "getting" tcFoo in this example. Below is how I do it now. Maybe I'm being thick, or maybe there's just no simpler way. This is my 'plugin' function in Foo.Plugin: > plugin = Plugin $ \opts todo -> do > hsc <- getHscEnv > dfs <- getDynFlags > fr <- liftIO $ findImportedModule hsc (mkModuleName "Foo") Nothing > mod <- case fr of > Found ml m -> return m > _ -> panic "Failed to (unambiguously) find 'Foo' (using findImportedModule)" > onc <- getOrigNameCache > let nms = lookupWithDefaultModuleEnv nms (panic "No names defined for module 'Foo'") mod > find_ d occ fnd nm > = maybe > (fail $ "Failed to find " ++ d ++ " '" ++ nm ++ "'") > fnd > (lookupOccEnv nms $ occ nm) > tcFind = find_ "TyCon" mkTcOcc lookupTyCon > dcFind = find_ "DataCon" mkDataOcc lookupDataCon > idFind = find_ "Id" mkVarOcc lookupId > tcFoo <- tcFind "Foo" > dcFoo <- dcFind "Foo" > idRunFoo <- idFind "runFoo" > return $ CoreDoPluginPass "Foo optimisation" (pass tcFoo dcFoo idRunFoo) : todo I have the following questions: 1) Is this a/the right way to "find" those things in the plugin? 2) There seems to be a lot to gain with quasi-quoting a la Template Haskell for people writing plugins to go with a library that they wrote. Can such QQ be done? Has it been considered? 3) Is findImportedModule the right function to find my starting point to begin with? 4) What is the 'Maybe FastString' argument in findImportedModule for? I've been trying to put in the FSs of PackageIDs, but they make the lookup fail. This (dumb) example really made me nervous: > fr <- liftIO $ findImportedModule hsc (mkModuleName "Foo") Nothing > mod <- case fr of > Found ml m -> do > fr' <- liftIO $ findImportedModule hsc (moduleName m) (packageIdFS $ packageId m) Here, fr' should always be a "Found ml' m'" such that ml == ml' and m == m', but... it consistently results in NotFound{} for me. Also, I find this especially round-about. Shouldn't Paths_Foo.hs (the Cabal-generated file) maybe contain variables for every module in the package? In my case it would thus contain some "modFoo :: Module" Comments and suggestions more than welcome! Regards, Philip

3 3

Looking for list comprehensions use cases
by Jan Stolarek 23 Jul '14

23 Jul '14

Haskellers, recently I've been looking into the possibility of creating some new optimisations for GHC. These would be mostly aimed at list comprehensions. Here's where I need your help: 1. Do you have complex list comprehensions usage examples from real code? By complex I mean nested list comprehensions, reading from more than one list ([ ...| x <- xs, y <- ys ... ]) etc. 2. Do you have list comprehensions code that you had to optimize by hand because GHC was unable to make them fast enough? Janek

2 1

GHC 7.10.1 tickets
by Austin Seipp 21 Jul '14

21 Jul '14

Hello *, We need to be sorting out tickets for 7.10.1. Last week, I spent some time remilestoning things to get them into the rough correct places (roughly), but we all need some help to get an idea of what we should fix for the release. Here's a query to look at: https://ghc.haskell.org/trac/ghc/query?status=!closed&milestone=7.10.1&orde… I have already categorized these tickets roughly, but we'll probably still address some of the priorities on existing tickets of course. These are all of the 7.10.1 tickets currently, but there are some important things to note: 1) There are a lot of them! 2) Most of the development team is probably not going to pay attention to many of them unless they are high or highest priority in Trac. (That's just the result of having so many tickets for 7.10.1 at the moment.) So I'm asking if people out there with the time can help chip in and give some input on the ticket! - If there's a ticket that interests you, please comment on it! - Say why you think it should have its priority elevated for 7.10.1. - It will certainly be easier if you offer to help. Then we can move it upwards and we'll look at it. Finally, if you are *really* dedicated or a newcomer - please go through the tickets and see if any of them can be closed, reassigned, marked as duplicates, etc. There are certainly some dead tickets and probably easy tickets for newcomers, so just spend a few minutes looking if you're interested! (Otherwise they just end up getting punted off in batch modifications) Thanks! ~~~~~~~ BTW, for developers, you can look at your assigned tickets for 7.10.1 here, it's also always on the sidebar: https://ghc.haskell.org/trac/ghc/query?owner=%24USER&status=infoneeded&stat… -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

1 0

Avoiding BlockedIndefinitelyOnSTM exceptions
by Gabriel Gonzalez 20 Jul '14

20 Jul '14

I have what may sound like an unusual request: I would like to automatically avoid `BlockedIndefinitelyOnSTM` exceptions with a primitive that looks something like this: safe :: STM a -> STM (Maybe a) This hypothetical `safe` primitive would attempt a transaction, and if `ghc` detects that this transaction would fail because of an `BlockedIndefinitelyOnSTM` exception it will return `Nothing` instead of throwing an uncatchable exception. I originally simulated a limited form of this behavior using `pipes-concurrency`. I instrumented the garbage collector (using weak references) to detect when an STM variable was garbage collected and to safely cancel any transactions that depended on those variables. You can see the implementation here: https://github.com/Gabriel439/Haskell-Pipes-Concurrency-Library/blob/23e7e2… The original purpose behind this was to easily read and write to a channel without having to count references to the channel. I reasoned that the garbage collector *already knew* how many open references there were to channel, so I thought "why not use the garbage collector to gracefully cancel transactions that would block just before they would trigger the exception?" This worked really well up until ghc-7.8 changed something and the above trick no longer works. To be honest, I'm surprised that it ever worked at all, which is why I'm not requesting restoring the original behavior. Instead, I think providing something like the above `safe` primitive would be nicer, if possible. Would it be possible to implement something like `safe`? Alternatively, is it possible to make the `BlockedIndefinitelyOnSTM` exception catchable? P.S. I'm also interested in learning more about what may have caused the change in behavior in the transition from ghc-7.6 to ghc-7.8. What changes were made to the interaction between STM and weak references that may have triggered this?

4 7

Failure compiling ghc-mtl with ghc-7.8.{2,3}
by i hamsa 20 Jul '14

20 Jul '14

I was trying to upgrade to ghc-7.8 the other day, and got this compilation failure when building ghc-mtl-1.2.1.0 (see the end of the message). I'm using the haskell overlay on Gentoo Linux straight out of the box, no local cabal installations of anything. Now I was told that other people can compile ghc-mtl with 7.8 just fine, so there must be something broken in my specific configuration. What would be an effective way to approach the situation? In the sources I see that an instance of MonadIO GHC.Ghc does exist. I don't understand these errors. Are there multiple different MonadIO classes in different modules? Thank you and happy hacking. Now the errors: Control/Monad/Ghc.hs:42:15: No instance for (GHC.MonadIO Ghc) arising from the 'deriving' clause of a data type declaration Possible fix: use a standalone 'deriving instance' declaration, so you can specify the instance context yourself When deriving the instance for (GHC.ExceptionMonad Ghc) Control/Monad/Ghc.hs:46:15: No instance for (MonadIO GHC.Ghc) arising from the 'deriving' clause of a data type declaration Possible fix: use a standalone 'deriving instance' declaration, so you can specify the instance context yourself When deriving the instance for (MonadIO Ghc) Control/Monad/Ghc.hs:49:15: No instance for (GHC.MonadIO Ghc) arising from the 'deriving' clause of a data type declaration Possible fix: use a standalone 'deriving instance' declaration, so you can specify the instance context yourself When deriving the instance for (GHC.GhcMonad Ghc) -- this is the real i

2 3

Avoiding BlockedIndefinitelyOnSTM exceptions
by Brandon Simmons 18 Jul '14

18 Jul '14

> I have what may sound like an unusual request: I would like to > automatically avoid `BlockedIndefinitelyOnSTM` exceptions with a > primitive that looks something like this: Have you seen ezyang's post here? Lots of hairy details that are probably relevant http://blog.ezyang.com/2011/07/blockedindefinitelyonmvar/ Brandon

1 0

extra "ambiguous type variable" errors after a "couldn't match" error?
by Evan Laforge 17 Jul '14

17 Jul '14

7.8.3 has a new behaviour where a "plain" type error will cause "ambiguous type variable" errors, e.g.: module M where broken :: [Int] broken = () ambiguous :: a -> [String] ambiguous _ = map show [1..] When imported in ghci, I get: M.hs:4:10: Couldn't match expected type ‘[Int]’ with actual type ‘()’ In the expression: () In an equation for ‘broken’: broken = () M.hs:7:19: No instance for (Show a0) arising from a use of ‘show’ The type variable ‘a0’ is ambiguous [ ... and then more for Enum and Num ] It seems like the 'a' type variable causes this to happen. But I don't see why a type error in another place should cause 'ambiguous' to become ambiguous.

2 2

Why no `instance (Monoid a, Applicative f)=> Monoid (f a)` for IO?
by Brandon Simmons 15 Jul '14

15 Jul '14

It seems to me that this should be true for all `f a` like: instance (Monoid a, Applicative f)=> Monoid (f a) where mappend = liftA2 mappend mempty = pure mempty But I can't seem to find the particular `instance (Monoid a)=> Monoid (IO a)` anywhere. Would that instance be incorrect, or does it live somewhere else? FWIW I noticed this when I started thinking about an instance I wanted for 'contravariant': instance (Monoid a, Applicative f)=> Monoid (Op (f a) b) where mempty = Op $ const $ pure mempty mappend (Op f) (Op g) = Op (\b-> liftA2 mappend (f b) (g b)) at which point I realized (I think) all `f a` are monoidal, and so we ought to be able to get the instance above with just a deriving Monoid. Brandon

2 2

Fwd: how to get ghci to load compiled modules in 7.8?
by Evan Laforge 14 Jul '14

14 Jul '14

I sent this to haskell-cafe, but there was no response. On stackoverflow there was no response either. I'm trying one last time, but adding ghc-users (which I should have done at the beginning!). Surely it can't be that no one knows how to load modules in ghci? I know a lot of work was done to enable this, as in https://ghc.haskell.org/trac/ghc/wiki/DynamicByDefault, it seems a waste if no one actually knows how to use it! The 7.8.1 release notes make reference to -dynamic-too, and an unexplained "Dynamic Ghci", but implies ghci should just work. Do I need to compile ghci myself in a dynamic way? The DynamicByDefault page also implies that, but I assumed the binary distributions would come with it compiled the right way. This has almost disabled ghci for my work (it can be used, but very slowly and with much retyping of commands, and I find myself avoiding the REPL now), so it's a big regression from 7.6! I added another paragraph from the stackoverflow question. Also, I can't get this to work on linux either, not just OS X. BTW, I got a nice bump in my profiles after upgrading, so 7.8 is mostly good news. Just this one awkward thing keeps it from being all good news. ---------- Forwarded message ---------- I recently upgraded to 7.8.2 and I have a silly question. How do you get ghci to load compiled modules? When I try this: % cat >T.hs module T where x :: Int x = 42 % ghc -c -dynamic-too T.hs % s T.dyn_hi T.dyn_o T.hi T.hs T.o % ghci GHCi, version 7.8.2: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading package filepath-1.3.0.2 ... linking ... done. Prelude> :l T [1 of 1] Compiling T ( T.hs, interpreted ) Ok, modules loaded: T. *T> It still loads the file interpreted, even though there is a .dyn_o present. What am I doing wrong? This is on x86-64 OS X. There is one other thing which may be related. Since I load everything interpreted now, I've noticed that the input gets very laggy when I have a hundred or so modules loaded. Also the haskeline state gets confused, e.g. I hit escape k to get the previous line, but then it spontaneously goes back into insert mode again. It stays balky and awkward for about 15 seconds before returning to normal slightly. It's almost as if, after loading all the bytecode, it's still doing tons of work in the background, with constant GC freezes. But what work could it be doing? The bytecode is loaded and I haven't asked it to do anything yet! I don't know if this is new to 7.8, or if it's a result of loading bytecode instead of binary. Update: loading with -fobject-code to force compilation reduces some of the balkiness, but some is still there! So maybe this is a regression from 7.6?

2 5

Re: Installing ghc-7.8.3 OS X bindist fails on Xcode 4 CLI-only machine
by Christiaan Baaij 14 Jul '14

14 Jul '14

Thanks, the work-around did the trick. On 14 July 2014 16:34, Mark Lentczner <mark.lentczner(a)gmail.com> wrote: > Yes - this is a known problem in GHC (#9257 > <https://ghc.haskell.org/trac/ghc/ticket/9257>) > The problem is that there is one gcc invocation in the "make install" step > (!) and that the clang/gcc detection isn't applied at bindist configuire > time. Hence, that gcc invocation is based on the compiler of the machine > that built the bindist (clang), not the compiler of the machine it is being > installed on (gcc). > > Note that this doesn't affect the installed GHC system: The compiler > detection at bindist configure time *is* applied to the ghc tree it > installs, just not the bindist make itself! > > Work around is very easy: > > make install CC_CLANG_BACKEND=0 > > > - Mark > >

1 0