- Glasgow-haskell-users

Re: Overlapping and incoherent instances
by Brandon Allbery 29 Jul '14

29 Jul '14

On Tue, Jul 29, 2014 at 8:33 AM, Andreas Abel <andreas.abel(a)ifi.lmu.de> wrote: > +1. I like Niklas' syntax better. Also OVERLAPPABLE is a horrible word, > OVERLAPPING sound less formidable (even though it might be slightly less > accurrate). We already get "overlap ok" in instance-related type errors, so OVERLAP_OK wouldn't be particularly alien even if it doesn't quite fit in with existing pragmas. -- brandon s allbery kf8nh sine nomine associates allbery.b(a)gmail.com ballbery(a)sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

3 2

Type family stopped compiling on upgrade from GHC 7.6.3 to 7.8.3
by cheater00 . 26 Jul '14

26 Jul '14

Hi, I was experimenting a bit with type families recently and ran into a bit of an issue. Given that I don't know type families that well yet, I was wondering if I made an error somewhere. One thing is that I can't find any relevant changes in the GHC release notes for 7.8.1, .2 or .3. Maybe this code contains an error which 7.6.3 simply wasn't able to find? Thanks. -------- -- this code compiles in 7.6.3, but breaks in 7.8.3 with the following message: -- TypeFamilies.hs:14:31: -- ‘End’ of kind ‘*’ is not promotable -- In the kind ‘End’ -- In 7.6.3, using :kind!, I can see that the type synonyms contained in the family do work the way I intend them to. {-# Language GADTs , TypeFamilies , DataKinds #-} module TypeFamilies where data End = Least | Spot Float | Most deriving (Eq, Show) data Interval = IntervalCons { left :: End, right :: End } deriving (Eq, Show) type family Interval2 (a :: End) (b :: End) :: Interval type instance Interval2 Least Most = IntervalCons Least Most type instance Interval2 (Spot l) Most = IntervalCons (Spot l) Most type instance Interval2 Least (Spot r) = IntervalCons Least (Spot r) type instance Interval2 (Spot l) (Spot r) = IntervalCons (Spot l) (Spot r)

3 5

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 21 Jul '14

21 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