- Glasgow-haskell-users

RE: Overlapping and incoherent instances
by Simon Peyton Jones 31 Jul '14

31 Jul '14

Andreas, remember that GHC 7.8 already implements (essentially) the same algorithm. The difference is that 7.8 offers only the brutal -XOverlappingInstances to control it. In your example of the decision you make when writing instance Bla a => Bla [a] vs instance {-# OVERLAPPABLE #-} Bla a => Bla [a] you are, with GHC 7.8, making precisely the same decision when you decide whether or not to add {-# LANGUAGE OverlappingInstances #-} to that module. Perhaps that wasn't clear in what I wrote; apologies. So your proposal seems to be this don't remove -XOverlappingInstances, because that will prevent programmers from "flipping on/off pragmas until their program goes through". It's hard to argue AGAINST providing the opportunity for more careful programmers to express their intentions more precisely, which is what the OVERLAP/OVERLAPPABLE pragmas do. Concerning deprecating OverlappingInstances, my gut feel is that it is positively a good thing to guide programmers towards a more robust programming style. But my reason for starting this thread was to see whether or not others' gut feel is similar. Simon | -----Original Message----- | From: Libraries [mailto:libraries-bounces@haskell.org] On Behalf Of | Andreas Abel | Sent: 31 July 2014 08:59 | To: Simon Peyton Jones; ghc-devs; GHC users; Haskell Libraries | (libraries(a)haskell.org) | Subject: Re: Overlapping and incoherent instances | | On 31.07.2014 09:20, Simon Peyton Jones wrote: | > Friends, in sending my message below, I should also have sent a link | > to | > | > https://ghc.haskell.org/trac/ghc/ticket/9242#comment:25 | | Indeed. | | Quoting from the spec: | | * Eliminate any candidate IX for which both of the following hold: | * There is another candidate IY that is strictly more specific; | that is, IY is a substitution instance of IX but not vice versa. | | * Either IX is overlappable or IY is overlapping. | | Mathematically, this makes a lot of sense. But put on the hat of | library writers, and users, and users that don't rtfm. Looking out | from under this hat, the one may always wonder whether one should make | one's generic instances OVERLAPPABLE or not. | | If I create a library with type class Bla and | | instance Bla a => Bla [a] | | I could be a nice library writer and spare my users from declaring | their Bla String instances as OVERLAPPING, so I'd write | | instance {-# OVERLAPPABLE #-} Bla a => Bla [a] | | Or maybe that would be malicious? | | I think the current proposal is too sophisticated. There are no | convincing examples given in the discussion so far that demonstrate | where this sophistication pays off in practice. | | Keep in mind that 99% of the Haskell users will never study the | instance resolution algorithm or its specification, but just flip | on/off pragmas until their code goes through. [At least that was my | approach: whenever GHC asks for one more LANGUAGE pragma, just throw it | in.] | | Cheers, | Andreas | | | > Comment 25 describes the semantics of OVERLAPPING/OVERLAPPABLE etc, | > which I signally failed to do in my message below, leading to | > confusion in the follow up messages. My apologies for that. | > | > Some key points: | > | > *There is a useful distinction between /overlapping/ and | > /overlappable/, but if you don't want to be bothered with it you can | > just say OVERLAPS (which means both). | > | > *Overlap between two candidate instances is allowed if /either/ has | > the relevant property. This is a bit sloppy, but reduces the | > annotation burden. Actually, with this per-instance stuff I think | > it'd be perfectly defensible to require both to be annotated, but | > that's a different discussion. | > | > I hope that helps clarify. | > | > I'm really pretty certain that the basic proposal here is good: it | > implements the current semantics in a more fine-grained manner. My | > main motivation was to signal the proposed deprecation of the global | > per-module flag -XoverlappingInstances. Happily people generally | seem | > fine with this. It is, after all, precisely what deprecations are | for | > ("the old thing still works for now, but it won't do so for ever, and | > you should change as soon as is convenient"). | > | > Thanks | > | > Simon | > | > *From:*Libraries [mailto:libraries-bounces@haskell.org] *On Behalf Of | > *Simon Peyton Jones | > *Sent:* 29 July 2014 10:11 | > *To:* ghc-devs; GHC users; Haskell Libraries (libraries(a)haskell.org) | > *Subject:* Overlapping and incoherent instances | > | > Friends | > | > One of GHC's more widely-used features is overlapping (and sometimes | > incoherent) instances. The user-manual documentation is here | > <http://www.haskell.org/ghc/docs/latest/html/users_guide/type-class- | extensions.html#instance-overlap>. | > | > The use of overlapping/incoherent instances is controlled by LANGUAGE | > pragmas: OverlappingInstances and IncoherentInstances respectively. | > | > However the overlap/incoherent-ness is a property of the **instance | > declaration** itself, and has been for a long time. Using LANGUAGE | > OverlappingInstances simply sets the "I am an overlapping instance" | > flag for every instance declaration in that module. | > | > This is a Big Hammer. It give no clue about **which** particular | > instances the programmer is expecting to be overlapped, nor which are | > doing the overlapping. It brutally applies to every instance in | the | > module. Moreover, when looking at an instance declaration, there is | > no nearby clue that it might be overlapped. The clue might be in the | > command line that compiles that module! | > | > Iavor has recently implemented per-instance-declaration pragmas, so | > you can say | > | > instance {-# OVERLAPPABLE #-} Show a => Show [a] where ... | > | > instance {-# OVERLAPPING #-} Show [Char] where ... | > | > This is much more precise (it affects only those specific instances) | > and it is much clearer (you see it when you see the instance | declaration). | > | > This new feature will be in GHC 7.10 and I'm sure you will be happy | > about that. *But I propose also to deprecate the LANGUAGE pragmas | > OverlappingInstances and IncoherentInstances*, as way to encourage | > everyone to use the new feature instead of the old big hammer. The | > old LANGUAGE pragmas will continue to work, of course, for at least | > another complete release cycle. We could make that two cycles if it | was helpful. | > | > However, if you want deprecation-free libraries, it will entail a | wave | > of library updates. | > | > This email is just to warn you, and to let you yell if you think this | is | > a bad idea. It would actually not be difficult to retain the old | > LANGUAGE pragmas indefinitely - it just seems wrong not to actively | > push authors in the right direction. | > | > These deprecations of course popped up in the test suite, so I've | been | > replacing them with per-instance pragmas there too. Interestingly in | > some cases, when looking for which instances needed the pragmas, I | > found...none. So OverlappingInstances was entirely unnecessary. Maybe | > library authors will find that too! | > | > Simon | > | > | > | > _______________________________________________ | > Libraries mailing list | > Libraries(a)haskell.org | > http://www.haskell.org/mailman/listinfo/libraries | > | | | -- | Andreas Abel <>< Du bist der geliebte Mensch. | | Department of Computer Science and Engineering Chalmers and Gothenburg | University, Sweden | | andreas.abel(a)gu.se | http://www2.tcs.ifi.lmu.de/~abel/ | _______________________________________________ | Libraries mailing list | Libraries(a)haskell.org | http://www.haskell.org/mailman/listinfo/libraries

2 1

Re: Overlapping and incoherent instances
by Johan Tibell 30 Jul '14

30 Jul '14

On Wed, Jul 30, 2014 at 2:50 PM, Ivan Lazar Miljenovic <ivan.miljenovic(a)gmail.com> wrote: > On 30 July 2014 22:07, Andreas Abel <andreas.abel(a)ifi.lmu.de> wrote: >> I am a bit surprised by the distinction you outline below. This is maybe >> because I am native German, not English. The German equivalent of >> "overlap", "überschneiden/überlappen", is used exclusively in a symmetrical >> fashion. It's like in English, if I say "our interests overlap", then it is >> pointless to ask whether my interest are overlapping yours or are overlapped >> by yours. I want to alert you to the fact that non-native English speaker >> might have little understanding for a distinction between "OVERLAPPING" and >> "OVERLAPPABLE". >> >> Let's try to guess what it meant: Given >> >> A) instance Bla Char >> B) instance Bla a => Bla [a] >> C) instance Bla String >> >> you will in context A,B write C as OVERLAPPING, >> and in context A,C write B as OVERLAPPABLE? > > IIUC, B will be OVERLAPPABLE ("you can overlap this") and C will be > OVERLAPPING ("I'm overlapping an existing one") whereas C will be > plain. Apologies if this question doesn't make sense. Can we really talk about overlapping, given that instances can be written in different modules, moved between modules, or removed?

1 0

Re: Overlapping and incoherent instances
by Iavor Diatchki 29 Jul '14

29 Jul '14

Hello, I have no strong feelings about what words we use, but I wanted to point out that while we are thinking of names, we may want to consider 3 (and not just 2). Currently we have: * OVERLAPPING: This instances may overlap existing instances * OVERLAPPABLE: This instance may be overlapped by existing instances * OVERLAPS: This instance is both OVERLAPPING and OVERLAPPABLE Of course, the 3rd one (OVERLAPS) could be replaced by a comma separated list of the first two, but I could not see how to make this work easily with GHC's pragmas. It would not be hard to simply allow 2 pragmas after the `instance` keyword, but both of those seem rather long. Either way, I'll keep an eye on the discussion, and would be happy to change the names if a consesus is reached. -Iavor On Tue, Jul 29, 2014 at 9:57 AM, David Thomas <davidleothomas(a)gmail.com> wrote: > Honestly, I think "OVERLAPS" and "OVERLAPPED" are perfectly clear. > > On Tue, Jul 29, 2014 at 9:52 AM, David Feuer <david.feuer(a)gmail.com> > wrote: > > CAN-OVERLAP and CAN-BE-OVERLAPPED are nice and clear. A little long, > perhaps. > > > > On Tue, Jul 29, 2014 at 12:29 PM, Simon Peyton Jones > > <simonpj(a)microsoft.com> wrote: > >> CAN_OVERLAP and CAN_BE_OVERLAPPED? > >> > >> > >> > >> (instead of OVERLAPPING and OVERLAPPABLE) > >> > >> > >> > >> Or CAN-OVERLAP, CAN-BE-OVERLAPPED > >> > >> > >> > >> That’s ok with me if that’s what you all want! > >> > >> > >> > >> Simon > >> > >> > >> > >> From: Glasgow-haskell-users > >> [mailto:glasgow-haskell-users-bounces@haskell.org] On Behalf Of > Krzysztof > >> Skrzetnicki > >> Sent: 29 July 2014 16:56 > >> To: Brandon Allbery > >> Cc: Simon Peyton Jones; Andreas Abel; GHC users; Haskell Libraries > >> (libraries(a)haskell.org) ghc-devs > >> > >> > >> Subject: Re: Overlapping and incoherent instances > >> > >> > >> > >> How about CAN_OVERLAP? > >> > >> -- > >> Krzysztof > >> > >> 29-07-2014 15:40, "Brandon Allbery" <allbery.b(a)gmail.com> napisał(a): > >> > >> 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 > >> > >> > >> _______________________________________________ > >> Libraries mailing list > >> Libraries(a)haskell.org > >> http://www.haskell.org/mailman/listinfo/libraries > >> > >> > >> _______________________________________________ > >> Libraries mailing list > >> Libraries(a)haskell.org > >> http://www.haskell.org/mailman/listinfo/libraries > >> > > _______________________________________________ > > Libraries mailing list > > Libraries(a)haskell.org > > http://www.haskell.org/mailman/listinfo/libraries > _______________________________________________ > Libraries mailing list > Libraries(a)haskell.org > http://www.haskell.org/mailman/listinfo/libraries >

1 0

Re: Overlapping and incoherent instances
by Herbert Valerio Riedel 29 Jul '14

29 Jul '14

On 2014-07-29 at 11:29:45 +0200, Niklas Hambüchen wrote: >> instance {-# OVERLAPPABLE #-} Show a => Show [a] where … > > Is the syntax somewhat flexible in where the pragma can be placed? > For example, some might prefer > > {-# OVERLAPPING #-} > instance Show [Char] where … This variant may also be more convenient in cases where you need to CPP-guard that pragma, as it's on a separate line.

6 7

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