- ghc-devs - Haskell.org

type-checker plugin API/behaviour change
by Christiaan Baaij 18 Jul '18

18 Jul '18

Hi devs, Currently, type-checker plugins get to tell the solver its progress using a [TcPluginResult]( http://hackage.haskell.org/package/ghc-8.4.1/docs/TcRnTypes.html#t:TcPlugin… ): ``` data TcPluginResult = TcPluginContradiction [Ct] -- ^ The plugin found a contradiction. -- The returned constraints are removed from the inert set, -- and recorded as insoluble. | TcPluginOk [(EvTerm,Ct)] [Ct] -- ^ The first field is for constraints that were solved. -- These are removed from the inert set, -- and the evidence for them is recorded. -- The second field contains new work, that should be processed by -- the constraint solver. ``` So when asked to solve a _set_ of constraints, a tc plugin basically gets to say: A) This _one_ constraint out of the entire set is wrong, or B) The following _subset_ of constraints is solved (plus some new wanted constraints) Supposedly, picking A leads to better error messages when a constraint is obviously bad (i.e. Int ~ Char). However, the issue is that when a tc plugin picks A, then it will not be called again for the whole set of constraint it originally got; which in my use-case basically leads to a complete set of (actually solvable) unsolved constraints. This is "bad" because it leads to very confusing error messages, when 1. Start with a correct program: All constraints solvable => no errors reported 2. Add one line of code that doesn't type check 3. All constraints unsolvable => errors reported in parts of the program that used to type-check. I thought of multiple possible solutions, but changing TcPluginResult to: ``` data TcPluginResult = TcPluginResult { contradictions :: [Ct] -- ^ All of the contradictions the plugin found , solved :: [(EvTerm,Ct)] -- ^ Constraints that were solved , new :: [Ct] -- ^ New work to be processed by the rest of the constraint solver } ``` seems the best one as it allows a tc plugin to report _all_ the constraints that are bad, and _all_ the constraints that are bad. Thoughts? Perhaps a better solution? Thanks, Christiaan

2 1

Write barrier for stack updates?
by Ömer Sinan Ağacan 18 Jul '18

18 Jul '18

Hi Simon, I'm a bit confused about stack updates in generated code and write barriers. Because stacks are mutable (we push new stuff or maybe even update existing frames?) it seems to me that we need one these two, similar to other mutable objects: - Always keep all stacks in mut_lists - Add write barriers before updates However looking at some of the primops like catch# and the code generator that generates code that pushes update frames I can't see any write barriers and the GC doesn't always add stacks to mut_lists (unlike e.g. MUT_ARR_PTRS). I also thought maybe we add a stack to a mut_list when we switch to the TSO that owns it or we park the TSO, but I don't see anything relevant in Schedule.c or ThreadPaused.c. So I'm lost. Could you say a few words about how we deal with mutated stacks in the GC, so that if an old stack points to a young object we don't collect the young object in a minor GC? Thanks, Ömer

2 2

submodule repos on GitHub
by Richard Eisenberg 17 Jul '18

17 Jul '18

Hi devs, The Newcomers page (https://ghc.haskell.org/trac/ghc/wiki/Newcomers) recommends cloning GHC with > git clone --recursive git://github.com/ghc/ghc I believe my students did this with success several weeks ago. But trying it again today leads to trouble with some submodules, e.g.: > Cloning into '/Users/rae/ltemp/ghc-test/libraries/Cabal'... > fatal: remote error: > ghc/packages/Cabal is not a valid repository name > Email support(a)github.com for help > fatal: clone of 'git://github.com/ghc/packages/Cabal.git' into submodule path '/Users/rae/ltemp/ghc-test/libraries/Cabal' failed > Is there something wrong in the internets? Or should we update the Newcomers page? Thanks, Richard

4 6

Cmm learning tools
by Daniel Cartwright 17 Jul '18

17 Jul '18

Hello all, I've recently become interested in learning Cmm, but cannot seem to find any concrete learning resources or extensive papers. It doesn't help that the web seems to contain a lot of useless information for a newcomer to Cmm. If anyone could provide some reading material about Cmm, I would be most grateful.

3 5

Is it possible to enhance the vector STG registers(Xmm, Ymm, Zmm) with more information?
by Abhiroop Sarkar 17 Jul '18

17 Jul '18

Hello all, I am currently working on adding support for SIMD operations to the native code generator. One of the roadblocks I faced recently was the definition of the `globalRegType` function in "compiler/cmm/CmmExpr.hs". The `globalRegType` function maps the STG registers to the respective `CmmType` datatype. For Xmm, Ymm, Zmm registers the function defines globalRegType like this: https://github.com/ghc/ghc/blob/master/compiler/cmm/CmmExpr.hs#L585-L587 Consider the case for an Xmm register, the above definition limits an Xmm register to hold only vectors of size 4. However we can store 2 64-bit Doubles or 16 Int8s or 8 Int16s and so on The function `globalRegType` is internally called by the function `cmmRegType` ( https://github.com/ghc/ghc/blob/838b69032566ce6ab3918d70e8d5e098d0bcee02/co…) which is itself used in a number of places in the x86 code generator. In fact depending on the result of the `cmmRegType` function is another important function `cmmTypeFormat` defined in Format.hs whose result is used to print the actual assembly instruction. I have extended all the other Format types to include VectorFormats, however this definition of the `globalRegType` seems incorrect to me. Looking at the signature of the function itself: `globalRegType :: DynFlags -> GlobalReg -> CmmType` its actually difficult to predict the CmmType by just looking at the GlobalReg in case of Xmm, Ymm, Zmm. So thats why my original question how do I go about solving this. Should I modify the GlobalReg type to contain more information like Width and Length(for Xmm, Ymm, Zmm) or do I somehow pass the length and width information to the globalRegType function? Thanks Abhiroop Sakar

3 8

RE: [commit: ghc] master: Remove ASSERTion about increasing TcLevels (a754a42)
by Simon Peyton Jones 15 Jul '18

15 Jul '18

Richard, weren't you going to open a ticket to track this? It ought to hold! Simon | -----Original Message----- | From: ghc-commits <ghc-commits-bounces(a)haskell.org> On Behalf Of | git(a)git.haskell.org | Sent: 15 July 2018 02:28 | To: ghc-commits(a)haskell.org | Subject: [commit: ghc] master: Remove ASSERTion about increasing TcLevels | (a754a42) | | Repository : ssh://git@git.haskell.org/ghc | | On branch : master | Link : | https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fghc.haske | ll.org%2Ftrac%2Fghc%2Fchangeset%2Fa754a420b53cd2210ef60dcd695bf3334af2e40 | 0%2Fghc&data=02%7C01%7Csimonpj%40microsoft.com%7C9b543b1c10fd4fcae84c | 08d5e9f2325b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636672148791196 | 487&sdata=o8HfV%2FQqEfk0wKuW1XStZXzkn%2FkyDbw8DsfBIpTnzpw%3D&rese | rved=0 | | >--------------------------------------------------------------- | | commit a754a420b53cd2210ef60dcd695bf3334af2e400 | Author: Richard Eisenberg <rae(a)cs.brynmawr.edu> | Date: Thu Jul 12 16:10:34 2018 -0400 | | Remove ASSERTion about increasing TcLevels | | This removes an ASSERTion that TcLevels should increase by | exactly one in every implication. While this is a sensible | goal, it's not true today, and we should not be crippling | DEBUG for everyone while debugging this. | | The ASSERT was added in 261dd83cacec71edd551e9c581d05285c9ea3226 | | | >--------------------------------------------------------------- | | a754a420b53cd2210ef60dcd695bf3334af2e400 | compiler/typecheck/TcSimplify.hs | 8 +++++++- | 1 file changed, 7 insertions(+), 1 deletion(-) | | diff --git a/compiler/typecheck/TcSimplify.hs | b/compiler/typecheck/TcSimplify.hs | index 13a3f73..c57ef56 100644 | --- a/compiler/typecheck/TcSimplify.hs | +++ b/compiler/typecheck/TcSimplify.hs | @@ -1495,7 +1495,8 @@ solveImplication imp@(Implic { ic_tclvl = tclvl | = do { inerts <- getTcSInerts | ; traceTcS "solveImplication {" (ppr imp $$ text "Inerts" <+> ppr | inerts) | | - ; when debugIsOn check_tc_level | + -- commented out; see `where` clause below | + -- ; when debugIsOn check_tc_level | | -- Solve the nested constraints | ; (no_given_eqs, given_insols, residual_wanted) | @@ -1544,10 +1545,15 @@ solveImplication imp@(Implic { ic_tclvl = tclvl | -- TcLevels must be strictly increasing (see (ImplicInv) in | -- Note [TcLevel and untouchable type variables] in TcType), | -- and in fact I thinkthey should always increase one level at a | time. | + | + -- Though sensible, this check causes lots of testsuite failures. It | is | + -- remaining commented out for now. | + {- | check_tc_level = do { cur_lvl <- TcS.getTcLevel | ; MASSERT2( tclvl == pushTcLevel cur_lvl | , text "Cur lvl =" <+> ppr cur_lvl $$ | text "Imp lvl =" <+> ppr tclvl ) } | + -} | | ---------------------- | setImplicationStatus :: Implication -> TcS (Maybe Implication) | | _______________________________________________ | ghc-commits mailing list | ghc-commits(a)haskell.org | https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.hask | ell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc- | commits&data=02%7C01%7Csimonpj%40microsoft.com%7C9b543b1c10fd4fcae84c | 08d5e9f2325b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636672148791196 | 487&sdata=V1pVxb4Crgjv04p9ZCGx7BDis0eXSV2fV9MDOPZXZEA%3D&reserved | =0

1 0

Request for Nominations to the GHC Steering Committee
by Joachim Breitner 14 Jul '18

14 Jul '18

Dear Haskell community, the GHC Steering committee is seeking nominations for a new member. The committee scrutinizes, nitpicks, improves, weights and eventually accepts or rejects proposals that extend or change the language supported by GHC and other (public-facing) aspects of GHC. Our processes are described at https://github.com/ghc-proposals/ghc-proposals which is also the GitHub repository where proposals are proposed. We are looking for a member who has the ability * to understand such language extension proposals, * to find holes and missing corner cases in the specifications, * foresee the interaction with other language features and specifications, * comment constructively and improve the proposals, * judge the cost/benefit ratio and * finally come to a justifiable conclusion. We look for committee members who have some of these properties: * have substantial experience in writing Haskell applications or libraries, which they can use to inform judgements about the utility or otherwise of proposed features, * have made active contributions to the Haskell community, for some time, * have expertise in language design and implementation, in either Haskell or related languages, which they can share with us. The committee’s work requires a small, but non-trivial amount of time, especially when you are assigned a proposal for shepherding. We estimate the workload to be around 2 hours per week, and our process works best if members usually respond to technical emails within 1-2 weeks (within days is even better). Please keep that in mind if your email inbox is already overflowing. The GHC developers themselves are already well represented already. We seek Haskell _users_ more than GHC hackers. There is no shortage of people who are very eager to get fancy new features into the language, both in the committee and the wider community. But each new feature imposes a cost, to implement, to learn, (particularly) through its unexpected interaction with other features. We need to strike a balance, one that encourages innovation (as GHC always has) while still making Haskell attractive for real-world production use and for teaching. We therefore explicitly invite “conservative” members of the community to join the committee. To make a nomination, please send an email to me (as the committee secretary) at mail(a)joachim-breitner.de until July 23th. I will distribute the nominations among the committee, and we will keep the nominations and our deliberations private. We explicitly encourage self-nominations. You can nominate others, but please obtain their explicit consent to do so. (We don’t want to choose someone who turns out to be unable to serve.) On behalf of the committee, Joachim Breitner -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

1 0

RE:: Can a TC plugin create new skolem vars when simplifying Givens?
by Simon Peyton Jones 11 Jul '18

11 Jul '18

Nick writes Here's a small indicative example. In the "simplify Givens" step, the plugin receives [G] (p `Union` Singleton A) ~ (q `Union` Singleton B) and I would ideally simplify that to [G] p ~ (x `Union` Singleton B) [G] q ~ (x `Union` Singleton A) If we think of Union as a type-level function (which it is?), then the step you outline above is similar to what happens during “flattening” of the Givens. We get this: [G] fsk1 ~ p `Union` Singleton B (CFunEqCan) [G] fsk2 ~ q `Union` Singleton A (CFunEqCan) [G] fsk1 ~ fsk2 (CTyEqCan) * The newly generated skolems are called “flatten-skolems” or fsks for short. * The new skolems are kept in the `inert_fsks` field of the `InertSet`. * A new one is created by `TcSMonad.newFlattenSkolem` * All fsks are eliminated by TsSMonad.unflattenGivens Returning to your point, you are exploiting a property of sets that allows you to say that if p U X = q U Y Then suppose r = p • q then p = r U Y, q = r U X And now we can eliminate all uses of p, q in favour of r. But if you do this in a type system, we have a problem: where is ‘r’ bound? E.g. if you have f :: forall p q. (p `Union` A) ~ (q `Union` B) => blah Then p, q are bound by the forall, but r is not. To put it another way, what well-typed Core program would you like to generate? You could do this: [G] fsk1 ~ p `Union` Singleton B (CFunEqCan) [G] fsk2 ~ q `Union` Singleton A (CFunEqCan) [G] fsk3 ~ p `Intersect` q (CFunEqCan) [G] fsk4 ~ fsk3 `Union` Singleton B (CFunEqCan) [G] fsk5 ~ fsk3 `Union` Singleton A (CFunEqCan) [G] fsk1 ~ fsk2 (CTyEqCan) [G] p ~ fks4 (CTyEqCan) [G] q ~ fsk5 (CTyEqCan) The ‘r’ is just fsk3. It’ll be eliminated by unflattenGivens, so there is no problem with scoping. I have no idea whether that’ll help you prove the things you want to prove! Simon From: ghc-devs <ghc-devs-bounces(a)haskell.org<mailto:ghc-devs-bounces@haskell.org>> On Behalf Of Nicolas Frisby Sent: 24 June 2018 19:01 To: ghc-devs(a)haskell.org<mailto:ghc-devs@haskell.org> Subject: Can a TC plugin create new skolem vars when simplifying Givens? I'm still spending the occasional weekend working on a type checker plugin for row types (actually "set" types at first, but I haven't thought of a less ambiguous term for that). One point of complexity in the plugin has to do with creating fresh variables when simplifying Givens. Some constraints are traditionally simplified by introducing a fresh variable. For Wanted constraints, that's easy (newFlexiTyVar). For Givens, though, I haven't figured out how to do it. This email is just to ask these two questions: 1) Is there a function to add a new skolem variable when simplifying Givens? 2) Assuming not, is there a strong reason for there to never be such a function? Here's a small indicative example. In the "simplify Givens" step, the plugin receives [G] (p `Union` Singleton A) ~ (q `Union` Singleton B) and I would ideally simplify that to [G] p ~ (x `Union` Singleton B) [G] q ~ (x `Union` Singleton A) for some fresh skolem variable x. But I don't see how to properly create a fresh skolem variable in the Givens. If these were Wanteds, I would just use newFlexiTyVar. I think this is analogous to a hypothetical type checker plugin that eta expands tuples. If we were to simplify [G] ... (x :: (k1,k2)) ... to [G] ... '(x1 :: k1,x2 :: k2) ... we'd have to generate x1 and x2 somehow. The only method I'm aware of for that is to use Fst x and Snd x instead (ie type families). That might be acceptable for the tuple expansion example, but I'm very reticent to use something like that for the set types plugin. I have a plan to get by without creating these variables when simplifying Givens, but it's not simple. I'd be delighted if it were possible to create them. Hence my two questions listed above. Thank you for your time. -Nick

1 0

[ANNOUNCE] GHC 8.6.1-alpha1 available
by Ben Gamari 11 Jul '18

11 Jul '18

The GHC development team is pleased to announce the first alpha release leading up to GHC 8.6.1. The usual release artifacts are available from https://downloads.haskell.org/~ghc/8.6.1-alpha1 This is the first release (partially) generated using our new CI infrastructure. One known issue is that the haddock documentation is currently unavailable. This will be fixed in the next alpha release. Do let us know if you spot anything else amiss. As always, do let us know if you encounter any trouble in the course of testing. Thanks for your help! Cheers, - Ben

4 6

Re: How to use ghc-heap-view of ghc-8.6
by Patrick Dougherty 07 Jul '18

07 Jul '18

Hello, This effort mostly just brought the core of this [1] library into GHC. The main function you will want to try is `getClosureData`,which takes any value and returns the heap representation. There are some tricky aspects about evaluation, but I will refer you to the comments about `Box`s in [1]. As a shameless self-plug, I also wrote a bit about it. The first page is a brief intro to the heap, and the second is an example demonstrating how to track down a leaky accumulator. I also link to a few posts that sent me down this path. This doesn't implement all of the functionality of [1], but it pulls in enough that hopefully it should be a little more stable between GHC versions. Also, you should be able to recreate many of the functions by looking at the source of [1] on hackage. [1] http://hackage.haskell.org/package/ghc-heap-view-0.5.10/docs/GHC-HeapView.h… [2] https://patrickdoc.github.io/heap-view.html Best,Patrick P.S. Sorry about using [1] so many times. Both libraries are called heap-view which makes it a little difficult to distinguish. On Friday, July 6, 2018 10:10 PM, Takenobu Tani <takenobu.hs(a)gmail.com> wrote: Dear devs, I'm interested in ghc-heap-view of ghc-8.6. [1] Is there a document on how to use the ghc-heap-view of ghc-8.6? [1]: https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-8.6.1#Landedinmasterbranch Regards, Takenobu _______________________________________________ ghc-devs mailing list ghc-devs(a)haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

3 3