- Glasgow-haskell-users

Derived Functor instance for void types
by David Feuer 15 Jan '17

15 Jan '17

Currently, if you write data V a deriving Functor GHC generates fmap _ _ = error "Void fmap" This seems quite unfortunate, because it loses potentially useful error information: fmap (+ 3) (error "Too many snozzcumbers!") throws "Void fmap", rather than the much more precise "Too many snozzcumbers!" I've opened Trac #13117 to fix this, but I figured I should double check that no one is opposed. David Feuer

1 0

Narrower (per-method) GND
by David Feuer 12 Jan '17

12 Jan '17

There are some situations where we may want to use GND to derive some class methods when it's not applicable to others. For example, some people would very much like to add a join method to Monad, but doing so would prevent GND from working for Monad. Similarly, the distribute method of Data.Distributive.Distributive is incompatible with GND. In each of these cases, a perfectly valid, and efficient, way to derive the class would be to use the GND mechanism to derive the methods it works with and the default method definitions for the rest. To cover these cases, I think it would be nice to allow a method declaration to give a default definition intended to be used for GND. This may or may not be the same as the usual default. Some classes can support GND for some methods, but using defaults for the others would give poor implementations. To cover this case, I think it would be nice to add per-method GND-deriving syntax. This could look something like instance C T where deriving f g = ....

5 9

GHC rewrite rules for class operations & laws
by Conal Elliott 04 Jan '17

04 Jan '17

Is it possible to apply GHC rewrite rules to class methods? From what I’ve read and seen, class methods get eliminated early by automatically-generated rules. Is there really no way to postpone such inlining until a later simplifier stage? The GHC Users Guide docs say no <https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_ext…>, and suggests instead giving a duplicate vocabulary with somewhat awkward names for class methods. I’ve not seen this practice in libraries. I gather that we cannot therefore use class laws as optimizations in the form of rewrite rules, which seems a terrible loss. In Control.Category and Control.Arrow, I see rules for class laws but also header comments saying “The RULES for the methods of class Arrow may never fire e.g. compose/arr; see Trac #10528”. I’d appreciate a reality check about my conclusions as well as any strategies for using class laws in optimization. Thanks, -- Conal

5 9

[ANNOUNCE] Formation of the initial GHC Steering Committee
by Ben Gamari 04 Jan '17

04 Jan '17

Dear Haskell community, Over the past months we have discussed changes to GHC's process for collecting, discussing, and considering new language extensions, compiler features, and the like. Happily, we are now ready to move forward with our new proposal process. Towards this end, we have formed the GHC Steering Committee which will be responsible for evaluating the proposals that run through the process. The committee consists of the following members (with GitHub user names given parenthetically), * Chris Allen (@bitemyapp) * Joachim Breitner (@nomeata) * Manuel M T Chakravarty (@mchakravarty) * Iavor Diatchki (@yav) * Atze Dijkstra (@atzedijkstra) * Richard Eisenberg (@goldfirere) * Ben Gamari (@bgamari) * Simon Marlow (@simonmar) * Ryan Newton (@rrnewton) * Simon Peyton-Jones (@simonpj) The body will be chaired jointly by Simon Marlow and Simon Peyton-Jones. Since the ghc-proposals repository was created, it has accumulated nearly thirty pull requests describing a variety of compelling changes. We will consider these proposals to be at the beginning of their four-week discussion period. The goal of this discussion is to find and eliminate weaknesses of the proposal. The final proposal should address all valid points raised in the discussion. When you believe the proposal has converged, bring it to the steering committee and summarize the discussion in a pull request comment. If you would like to contribute a new proposal, please refer to the directions given in the ghc-proposals' repository README [1] and proposal submission guidelines [2]. Cheers, - Ben, on behalf of the GHC Steering Committee [1] https://github.com/ghc-proposals/ghc-proposals [2] https://github.com/ghc-proposals/ghc-proposals/blob/master/proposal-submiss…

1 0

[ANNOUNCE] GHC 8.0.2 release candidate 2
by Ben Gamari 28 Dec '16

28 Dec '16

Hello everyone, The GHC team is happy to announce the second candiate of the 8.0.2 release of the Glasgow Haskell Compiler. Source and binary distributions are available at http://downloads.haskell.org/~ghc/8.0.2-rc2/ This is the second and likely final release candidate leading up the 8.0.2 release. This release will fix a number of bugs found in 8.0.1 including, * Interface file build determinism (#4012). * Compatibility with macOS Sierra and GCC compilers which compile position-independent executables by default * Runtime linker fixes on Windows (see #12797) * A compiler bug which resulted in undefined reference errors while compiling some packages (see #12076) * Compatability with systems which use the gold linker * A number of memory consistency bugs in the runtime system * A number of efficiency issues in the threaded runtime which manifest on larger core counts and large numbers of bound threads. * A typechecker bug which caused some programs using -XDefaultSignatures to be incorrectly accepted. * More than two-hundred other bugs. See Trac [1] for a complete listing. This release candidate fixes a number of issues present in -rc1, * #12757, which lead to broken runtime behavior and even crashes in the presence of primitive strings. * #12844, a type inference issue affecting partial type signatures. * A bump of the `directory` library, fixing buggy path canonicalization behavior (#12894). Unfortunately this required a major version bump in `directory` and minor bumps in several other libraries. * #12912, where use of the `select` system call would lead to runtime system failures with large numbers of open file handles. If all goes well we should have a final 8.0.2 release out shortly after the new year. As always, let us know if you encounter trouble. Thanks to everyone who has contributed so far! Happy testing, - Ben [1] https://ghc.haskell.org/trac/ghc/query?status=closed&milestone=8.0.2&col=id…

3 3

Retro-Haskell: can we get seq somewhat under control?
by David Feuer 23 Dec '16

23 Dec '16

In the Old Days (some time before Haskell 98), `seq` wasn't fully polymorphic. It could only be applied to instances of a certain class. I don't know the name that class had, but let's say Seq. Apparently, some people didn't like that, and now it's gone. I'd love to be able to turn on a language extension, use an alternate Prelude, and get it back. I'm not ready to put up a full-scale proposal yet; I'm hoping some people may have suggestions for details. Some thoughts: 1. Why do you want that crazy thing, David? When implementing general-purpose lazy data structures, a *lot* of things need to be done strictly for efficiency. Often, the easiest way to do this is using either bang patterns or strict data constructors. Care is necessary to only ever force pieces of the data structure, and not the polymorphic data a user has stored in it. 2. Why does it need GHC support? It would certainly be possible to write alternative versions of `seq`, `$!`, and `evaluate` to use a user-supplied Seq class. It should even be possible to deal with strict data constructors by hand or (probably) using Template Haskell. For instance, data Foo a = Foo !Int !a would translate to normal GHC Haskell as data Foo a = Seq a => Foo !Int !a But only GHC can extend this to bang patterns, deal with the interactions with coercions, and optimize it thoroughly. 3. How does Seq interact with coercions and roles? I believe we'd probably want a special rule that (Seq a, Coercible a b) => Seq b Thanks to this rule, a Seq constraint on a type variable shouldn't prevent it from having a representational role. The downside of this rule is that if something *can* be forced, but we don't *want* it to be, then we have to hide it a little more carefully than we might like. This shouldn't be too hard, however, using a newtype defined in a separate module that exports a pattern synonym instead of a constructor, to hide the coercibility. 4. Optimize? What? Nobody wants Seq constraints blocking up specialization. Today, a function foo :: (Seq a, Foldable f) => f a -> () won't specialize to the Foldable instance if the Seq instance is unknown. This is lousy. Furthermore, all Seq instances are the same. The RTS doesn't actually need a dictionary to force something to WHNF. The situation is somewhat similar to that of Coercible, *but more so*. Coercible sometimes needs to pass evidence at runtime to maintain type safety. But Seq carries no type safety hazard whatsoever--when compiling in "production mode", we can just *assume* that Seq evidence is valid, and erase it immediately after type checking; the worst thing that could possibly happen is that someone will force a function and get weird semantics. Further, we should *unconditionally* erase Seq evidence from datatypes; this is necessary to maintain compatibility with the usual data representations. I don't know if this unconditional erasure could cause "laziness safety" issues, but the system would be essentially unusable without it. 4. What would the language extension do, exactly? a. Automatically satisfy Seq for data types and families. b. Propagate Seq constraints using the usual rules and the special Coercible rule. c. Modify the translation of strict fields to add Seq constraints as required. David Feuer

2 1

Re: Retro-Haskell: can we get seq somewhat under control?
by Edward Kmett 22 Dec '16

22 Dec '16

Actually, if you go back to the original form of Seq it would translate to data Seq a => Foo a = Foo !Int !a which requires resurrecting DatatypeContexts, and not data Foo a = Seq a => Foo !Int !a The former requires Seq to call the constructor, but doesn't pack the dictionary into the constructor. The latter lets you get the dictionary out when you pattern match on it. meaning it has to carry the dictionary around! Unfortunately, non-trivial functionality is lost. With the old DatatypeContext translation you can't always unpack and repack a constructor. Whereas with a change to an existential encoding you're carrying around a lot of dictionaries in precisely the structures that least want to carry extra weight. Both of these options suck relative to the status quo for different reasons. -Edward On Wed, Dec 21, 2016 at 2:14 PM, Index Int <vlad.z.4096(a)gmail.com> wrote: > There's a related GHC Proposal: > https://github.com/ghc-proposals/ghc-proposals/pull/27 > > On Wed, Dec 21, 2016 at 10:04 PM, David Feuer <david.feuer(a)gmail.com> > wrote: > > In the Old Days (some time before Haskell 98), `seq` wasn't fully > > polymorphic. It could only be applied to instances of a certain class. > > I don't know the name that class had, but let's say Seq. Apparently, > > some people didn't like that, and now it's gone. I'd love to be able > > to turn on a language extension, use an alternate Prelude, and get it > > back. I'm not ready to put up a full-scale proposal yet; I'm hoping > > some people may have suggestions for details. Some thoughts: > > > > 1. Why do you want that crazy thing, David? > > > > When implementing general-purpose lazy data structures, a *lot* of > > things need to be done strictly for efficiency. Often, the easiest way > > to do this is using either bang patterns or strict data constructors. > > Care is necessary to only ever force pieces of the data structure, and > > not the polymorphic data a user has stored in it. > > > > 2. Why does it need GHC support? > > > > It would certainly be possible to write alternative versions of `seq`, > > `$!`, and `evaluate` to use a user-supplied Seq class. It should even > > be possible to deal with strict data constructors by hand or > > (probably) using Template Haskell. For instance, > > > > data Foo a = Foo !Int !a > > > > would translate to normal GHC Haskell as > > > > data Foo a = Seq a => Foo !Int !a > > > > But only GHC can extend this to bang patterns, deal with the > > interactions with coercions, and optimize it thoroughly. > > > > 3. How does Seq interact with coercions and roles? > > > > I believe we'd probably want a special rule that > > > > (Seq a, Coercible a b) => Seq b > > > > Thanks to this rule, a Seq constraint on a type variable shouldn't > > prevent it from having a representational role. > > > > The downside of this rule is that if something *can* be forced, but we > > don't *want* it to be, then we have to hide it a little more carefully > > than we might like. This shouldn't be too hard, however, using a > > newtype defined in a separate module that exports a pattern synonym > > instead of a constructor, to hide the coercibility. > > > > 4. Optimize? What? > > > > Nobody wants Seq constraints blocking up specialization. Today, a > function > > > > foo :: (Seq a, Foldable f) => f a -> () > > > > won't specialize to the Foldable instance if the Seq instance is > > unknown. This is lousy. Furthermore, all Seq instances are the same. > > The RTS doesn't actually need a dictionary to force something to WHNF. > > The situation is somewhat similar to that of Coercible, *but more so*. > > Coercible sometimes needs to pass evidence at runtime to maintain type > > safety. But Seq carries no type safety hazard whatsoever--when > > compiling in "production mode", we can just *assume* that Seq evidence > > is valid, and erase it immediately after type checking; the worst > > thing that could possibly happen is that someone will force a function > > and get weird semantics. Further, we should *unconditionally* erase > > Seq evidence from datatypes; this is necessary to maintain > > compatibility with the usual data representations. I don't know if > > this unconditional erasure could cause "laziness safety" issues, but > > the system would be essentially unusable without it. > > > > 4. What would the language extension do, exactly? > > > > a. Automatically satisfy Seq for data types and families. > > b. Propagate Seq constraints using the usual rules and the special > > Coercible rule. > > c. Modify the translation of strict fields to add Seq constraints as > required. > > > > David Feuer > > _______________________________________________ > > ghc-devs mailing list > > ghc-devs(a)haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > _______________________________________________ > ghc-devs mailing list > ghc-devs(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >

2 1

Re: [ghc-devs]: Explicit inequality evidence
by Anthony Clayden 22 Dec '16

22 Dec '16

> On Dec 13, 2016, at 1:02 AM, David Feuer <david.feuer at gmail.com> wrote: > >> On Tue, Dec 13, 2016 at 12:49 AM, Oleg Grenrus <oleg.grenrus at iki.fi> wrote: >> >> I assume that in your rules, variables are not type families, otherwise >> >> x /~ y => f x /~ f y doesn't hold if `f` isn't injective. (e.g. type family F x where F x = ()) >> other direction is true though. > > I was definitely imagining them as first-class types; your point that > f x /~ f y => x /~ y even if f is a type family is an excellent one. > Hmm, yes except: how would evidence ever arise that f x /~ f y ? Would we ever get a 'wanted' constraint to that effect? More likely, we'd be trying to discriminate between instances in which picking some instance depends on f x /~ f y. I don't see that any of the overlap/closed type family work has got us away from the 'groundedness issues' observed in the HList paper. We have to improve both types to a grounded type constructor to get the evidence they're not equal. (Or at least that parameters in the same position are not equal, and that the type constructors are not familys and are the same arity.) AntC

1 0

[ghc-devs]: Explicit inequality evidence
by Anthony Clayden 18 Dec '16

18 Dec '16

[transferring to -users, because there's a much wider discussion] > > On Dec 13, 2016, at 15:04, Richard Eisenberg wrote: > > I've thought about inequality on and off for years now, The subject has appeared (in various guises) on Haskell forums since well before 2002 [1] -- which went into the 'OutsideIn(X)' model. Search the cafe on 'type disequality', for example. > >> On Tue, Dec 13, 2016 at 12:49 AM, Oleg Grenrus wrote: > >> First the bike shedding: Id prefer /~ and :/~:. And yes, usually discussed with /~ as the type inequality operator, since at least when ~ was introduced for type equality. > > ... but it's a hard nut to crack. Which is presumably why spj has never shown any interest. > > ... need evidence of inequality in Core, and > > a brand-spanking-new type safety proof. ... One rule of inference that David/Oleg haven't mentioned: If x /~ y and y ~ z then x /~ z. How does this go with (potentially) infinite type (family)s? Thanks Richard for the refs on type safety proofs. I wonder if anything in type safety relies on inequalities? (This would be with, say, overlaps + fundeps extensions.) FunDep 'confluence' (which Richard has re-christened 'coincident overlap' for closed type families), surely relies on proving at some use site that the types can never unify with such-and-such instance (or type family equation). For example if we have instance C a a where ... instance C a b where... We have to prove at a use site that the two types cannot unify, to justify picking the second instance. This goes badly with separate compilation: suppose the `C a a` instance is not visible in every module. I would love type inequality guards on instances to be explored as an alternative approach for overlap. (See some of my reponses to Richard [2].) In my example above: instance C a b | a /~ b where ... So the invisibility of the `C a a` instance would not upset any use sites. [1] Sulzmann and Stuckey 2002 'A theory of Overloading' [2] https://typesandkinds.wordpress.com/2013/04/29/coincident-overlap-in-type-f… AntC

1 0

Allow extra commas in module declarations or lists?
by Michael Burge 17 Dec '16

17 Dec '16

Some languages like Perl allow you to include additional commas in your lists, so that you can freely reorder them without worrying about adding or removing commas from the last or first item: my @array = ( 1, 2, 3, ); Perl even allows multiple redundant commas everywhere after the first element, which is less useful but has come up on occasion: my @array = (1,,,2,,,,,,,,,3,,,,,); I propose allowing an optional single extra comma at the end in module declarations, record declarations, record constructors, and list constructors: module Example ( module Example, SomeConstructor(..), ) where data SomeConstructor = SomeConstructor { foo :: Int, bar :: Int, } baz :: SomeConstructor -> SomeConstructor baz x = x { foo = 5, bar = 10, } qux :: [ Int ] qux = [ 1, 2, 3, ] What do you think?

4 3