October 2017 - ghc-devs

RE: GHC rewrite rule type-checking failure
by Simon Peyton Jones 03 Oct '17

03 Oct '17

But synthesising from what? And currently no: there is no type-class dictionary synthesis after the type checker. Not impossible I suppose, but one more fragility: a rule does not fire because some synthesis thing didn’t happen. Maybe give an as-simple-as-poss example of what you have in mind, now you understand the situation better? With all the type and dictionary abstractions written explicitly… S From: conal.elliott(a)gmail.com [mailto:conal.elliott@gmail.com] On Behalf Of Conal Elliott Sent: 03 October 2017 15:56 To: Simon Peyton Jones <simonpj(a)microsoft.com> Subject: Re: GHC rewrite rule type-checking failure Thanks, Simon. Your explanation make sense to me. Do you think that the rewrite rule mechanism could be enhanced to try synthesizing the needed dictionaries after LHS matching and before RHS instantiation? I'm doing as much now in my compiling-to-categories plugin, but without the convenience of using concrete syntax for the rules. Regard, - Conal On Tue, Oct 3, 2017 at 12:27 AM, Simon Peyton Jones <simonpj(a)microsoft.com<mailto:simonpj@microsoft.com>> wrote: * Is it feasible for GHC to combine the constraints needed LHS and RHS to form an applicability condition? I don’t think so. Remember that a rewrite rule literally rewrites LHS to RHS. It does not conjure up any new dictionaries out of thin air. In your example, (D k b) is needed in the result of the rewrite. Where can it come from? Only from something matched on the left. So GHC treats any dictionaries matched on the left as “givens” and tries to solve the ones matched on the left. If it fails you get the sort of error you see. One way to see this is to write out the rewrite rule you want, complete with all its dictionary arguments. Can you do that? Simon From: Glasgow-haskell-users [mailto:glasgow-haskell-users-bounces@haskell.org<mailto:glasgow-haskell-users-bounces@haskell.org>] On Behalf Of Conal Elliott Sent: 03 October 2017 01:03 To: Joachim Breitner <mail(a)joachim-breitner.de<mailto:mail@joachim-breitner.de>> Cc: glasgow-haskell-users(a)haskell.org<mailto:glasgow-haskell-users@haskell.org> Subject: Re: GHC rewrite rule type-checking failure Thanks very much for the reply, Joachim. Oops! I flubbed the example. I really `morph` to distribute over an application of `comp`. New code below (and attached). You're right that I wouldn't want to restrict the type of `morph`, since each `morph` *rule* imposes its own restrictions. My questions: * Is it feasible for GHC to combine the constraints needed LHS and RHS to form an applicability condition? * Is there any way I can make the needed constraints explicit in my rewrite rules? * Are there any other work-arounds that would enable writing such RHS-constrained rules? Regards, -- Conal ``` haskell {-# OPTIONS_GHC -Wall #-} -- Demonstrate a type checking failure with rewrite rules module RuleFail where class C k where comp' :: k b c -> k a b -> k a c instance C (->) where comp' = (.) -- Late-inlining version to enable rewriting. comp :: C k => k b c -> k a b -> k a c comp = comp' {-# INLINE [0] comp #-} morph :: (a -> b) -> k a b morph = error "morph: undefined" {-# RULES "morph/(.)" forall f g. morph (g `comp` f) = morph g `comp` morph f #-} -- • Could not deduce (C k) arising from a use of ‘comp’ -- from the context: C (->) -- bound by the RULE "morph/(.)" ``` On Mon, Oct 2, 2017 at 3:52 PM, Joachim Breitner <mail(a)joachim-breitner.de<mailto:mail@joachim-breitner.de>> wrote: Hi Conal, The difference is that the LHS of the first rule is mentions the `C k` constraint (probably unintentionally): *RuleFail> :t morph comp morph comp :: C k => k1 (k b c) (k a b -> k a c) but the LHS of the second rule side does not: *RuleFail> :t morph addC morph addC :: Num b => k (b, b) b A work-around is to add the constraint to `morph`: morph :: D k b => (a -> b) -> k a b morph = error "morph: undefined" but I fear that this work-around is not acceptable to you. Joachim Am Montag, den 02.10.2017, 14:25 -0700 schrieb Conal Elliott: > -- Demonstrate a type checking failure with rewrite rules > > module RuleFail where > > class C k where comp' :: k b c -> k a b -> k a c > > instance C (->) where comp' = (.) > > -- Late-inlining version to enable rewriting. > comp :: C k => k b c -> k a b -> k a c > comp = comp' > {-# INLINE [0] comp #-} > > morph :: (a -> b) -> k a b > morph = error "morph: undefined" > > {-# RULES "morph/(.)" morph comp = comp #-} -- Fine > class D k a where addC' :: k (a,a) a > > instance Num a => D (->) a where addC' = uncurry (+) > > -- Late-inlining version to enable rewriting. > addC :: D k a => k (a,a) a > addC = addC' > {-# INLINE [0] addC #-} > > {-# RULES "morph/addC" morph addC = addC #-} -- Fail > > -- • Could not deduce (D k b) arising from a use of ‘addC’ > -- from the context: D (->) b > > -- Why does GHC infer the (C k) constraint for the first rule but not (D k b) > -- for the second rule? > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users(a)haskell.org<mailto:Glasgow-haskell-users@haskell.org> > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.haskel…> -- Joachim Breitner mail(a)joachim-breitner.de<mailto:mail@joachim-breitner.de> http://www.joachim-breitner.de/<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim…>

2 1

[ANNOUNCE] GHC 8.2.1 release candidate 1
by Ben Gamari 03 Oct '17

03 Oct '17

Hello everyone, The GHC team is very pleased to announce the first candidate of the 8.2.1 release of the Glasgow Haskell Compiler. Source and binary distributions are available at https://downloads.haskell.org/~ghc/8.2.1-rc1/ This is the first of a few release candidates leading up the final 8.2.1 release. This release will feature, * A new type-indexed Typeable implementation * The long awaited Backpack * Deriving strategies for disambiguating DeriveAnyClass, GeneralizedNewtypeDeriving, and stock mechanisms * Overloaded record fields * Improved compiler performance * Better code generation through more robust tracking of join points * Compact regions for more efficient garbage collection and serialization * Better support for machines with non-uniform memory architectures * More robust support for levity (e.g. RuntimeRep) polymorphism * A simple interface for streaming eventlog data from live processes * Further refinement of DWARF support Unfortunately there are still a few known issues in this release, including a few compiler panics (#13233, #13509) and a memory leak in the simplifier (#13426) which may adversely affect heap sizes and compilation time for some modules. This memory leak unfortunately made it impossible to provide a 32-bit Windows distribution for this candidate; this will be resolved in -rc2. As always, please let us know if you have difficulty. Thanks to everyone who has contributed to this release! Happy testing, - Ben

5 15

GHC Threads affinity
by Michael Baikov 03 Oct '17

03 Oct '17

Greetings Currently GHC supports two kinds of threads - pinned to a specific capability (bound threads) and those it can migrate between any capabilities (unbound threads). For purposes of achieving lower latency in Haskell applications it would be nice to have something in between - threads GHC can migrate but within a certain subset of capabilities only. I'm developing a program that contains several kinds of threads - those that do little work and sensitive to latency and those that can spend more CPU time and less latency sensitive. I looked into several cases of increased latency in those sensitive threads (using GHC eventlog) and in all cases sensitive threads were waiting for non-sensitive threads to finish working. I was able to reduce worst case latency by factor of 10 by pinning all the threads in the program to specific capability but manually distributing threads (60+ of them) between capabilities (several different machines with different numbers of cores available) seems very fragile. World stopping GC is still a problem but at least in my case is much less frequently so. It would be nice to be able to allow GHC runtime to migrate a thread between a subset of capabilities using interface similar to this one: -- creates a thread that is allowed to migrate between capabilities according to following rule: ghc is allowed to run this thread on Nth capability if Nth `mod` size_of_word bit in mask is set. forkOn' :: Int -> IO () -> IO ThreadId forkOn' mask act = undefined This should allow to define up to 64 (32) distinct groups and allow user to break down their threads into bigger number of potentially intersecting groups by specifying things like capability 0 does latency sensitive things, caps 1..5 - less sensitive things, caps 6-7 bulk things. Anything obvious I'm missing? Any recommendations to how to implement this?

6 10

Proposal: Allow passing in linkable files from TH
by Alec Theriault 03 Oct '17

03 Oct '17

Hello, I have a TH feature request and I'd like to hear what people have to say about it. Here is the [Trac ticket][0]. I'm new to this, so if anything here sounds completely wrong, it probably is. TH currently lets you add in arbitrary C (and other languages usually supported by C compilers). That code is compiled for you and then linked in automatically. This is what makes the [`inline-c`][1] package possible. I'm proposing to extend this so that TH lets you pass in something that is already compiled and ready to be linked. The idea is that this would allow TH-level FFI to any language that can produce object files or libraries that have the C ABI. My immediate use-case is to make an `inline-rust` package where one can write Rust code straight into a Haskell quasiquote. In terms of a concrete API change, it would suffice to 1. add a `LangLinkable` constructor to the `ForeignSrcLang` data type 2. add a `qAddForeignFilePath :: ForeignSrcLang -> FilePath -> m ()` method to `Quasi` The code change is pretty small too (60 additions, 30 deletions) since the `addForeignFile` machinery is fully reusable (we just have to skip past the phase of calling the C compiler). # Pros: * Better TH FFI support * Simple to implement # Cons: * The proposed API is suboptimal: it allows for `qAddForeignFile LangLinkable "..."` although that that pretty much never makes sense since the thing being linked is not subject to `String` encoding Any thoughts? Alec [0]: https://ghc.haskell.org/trac/ghc/ticket/14298 [1]: https://hackage.haskell.org/package/inline-c

2 1

Re: [ANNOUNCE] GHC 8.2.2 release candidate 1
by Ryan Scott 02 Oct '17

02 Oct '17

I did a smoke test of Stackage Nightly's libraries [1] this afternoon using GHC 8.2.2. Only two libraries failed to build: extensible-0.4.5 and protolude-0.2, due to a change where type signatures like `foo :: forall k. forall (a :: k). ...` no longer compile without enabling TypeInType. I only mention this because the migration guide for 8.4 [2] currently gives the impression that this TypeInType change won't land until GHC 8.4. This doesn't appear to be case, though! Ryan S. ----- [1] https://www.stackage.org/nightly-2017-09-29 [2] https://ghc.haskell.org/trac/ghc/wiki/Migration/8.4?version=7#TypeInTypeisp…

3 9

Disabling Travis?
by Joachim Breitner 02 Oct '17

02 Oct '17

Hi, I wasn’t looking for a while I notice that the travis CI build of GHC has not been succeeding for two months, partly because build time exceeded the already much extended limits we have, partly because support for booting with 7.10 was dropped, but the .travis file was not used. A CI system that is not normally succeeding is pretty pointless, and will only confuse people who submit pull requests over GitHub who see failures. So if noone complains now I will soon disable building on Travis. Greetings, Joachim -- Joachim “nomeata” Breitner mail(a)joachim-breitner.de https://www.joachim-breitner.de/

3 14

Unifying verbosity flags (ticket #12822)
by Sergey Bykov 02 Oct '17

02 Oct '17

Hi, I'm working with the #12822 task, which is a refactoring for the verbosity flag. It should be reimplemented in a way, similar to the 'optimization' flag. After studying the codebase, specifically *optLevelFlags*, I'm stuck with the following questions: 1. Should I add a new data 'VerbosityFlag' similar to GeneralFlag, DumpFlag, etc or should I extend any of existing data types? 2. How to determine a set of verbosity options to implement? Is grepping through all the codebase and adding corresponding options a good approach? Thanks! -- Best regards, Sergey Bykov

2 2