April 2019 - ghc-devs

GHC HEAD documentation once again available
by Ben Gamari 01 May '19

01 May '19

TL;DR. A snapshot of GHC's documentation from the master branch can always be found at [2]. Hi everyone, Quite a while ago I made it a habit of periodically pushing documentation snapshots from GHC's master branch to downloads.haskell.org [1]. Unfortunately, despite some attempts at automating this process, this frequently grew out-of-date. I am happy to report that documentation snapshots are now generated as a product of GHC's CI process and made available here [2]. The old downloads.haskell.org URL redirects to [2] and consequently should now always be up-to-date. Let me know if you notice anything amiss. Cheers, - Ben [1] https://downloads.haskell.org/ghc/master/ [2] https://ghc.gitlab.haskell.org/ghc/doc/

4 6

GHC user manual
by Simon Peyton Jones 30 Apr '19

30 Apr '19

Where is the latest GHC user manual. I tried https://ghc.gitlab.haskell.org/ghc/doc/ but got a 502 failure. It would be good if it was easy to find the link from the developers home page https://gitlab.haskell.org/ghc/ghc/wikis/home Simon

2 4

GHC loose ends
by Simon Peyton Jones 30 Apr '19

30 Apr '19

Friends Like many people, I use my inbox as a to-do list. Over time, despite my best efforts, I accumulate a rising tide of GHC-related things (mostly tickets) where I feel I should do something, but it'd take too long to do today, so maybe tomorrow. Periodically I sweep all these into another folder, which makes me feel less oppressed by backlog. So this email is just to say: if you are waiting for some kind of response from me, please fell free to ping me. Simon

1 0

Type Annotations in the Presence of Injective Type Families, Bidirectional Pattern Synonyms, and Data Kinds
by Travis Whitaker 30 Apr '19

30 Apr '19

Hello GHC Devs, I've found a case in which annotating a bidirectional pattern synonym with a type signature causes the typechecker to reject an otherwise typeable program. Before filing a bug report I want to check that I'm thinking about this correctly. Consider this module: {-# LANGUAGE TypeFamilies , TypeFamilyDependencies , DataKinds , TypeOperators , GADTs , FlexibleContexts , PatternSynonyms #-} module Strange where data Expr a where Tuple :: NTup ts -> Expr (Flatten ts) data NTup (ts :: [*]) where Unit :: NTup '[] Pair :: Expr a -> NTup ts -> NTup (a ': ts) type family Flatten ts = r | r -> ts where Flatten '[] = () Flatten '[a, b] = (a, b) pattern P a b = Pair a (Pair b Unit) fstExpr :: Expr (a, b) -> (Expr a, Expr b) fstExpr (Tuple (P x y)) = (x, y) The idea is that an NTup '[a, b, c ...] should be isomorphic to an (a, b, c, ...), but removes a lot of repetitive code for dealing with Exprs of tuples. This module compiles with GHC 8.6.4 and GHC infers the expected type for P. P :: Expr a -> Expr a1 -> NTup '[a, a1] However, annotating P with this type causes typechecking fstExpr to fail with: Strange.hs:26:17: error: • Could not deduce: ts ~ '[a, b] from the context: (a, b) ~ Flatten ts bound by a pattern with constructor: Tuple :: forall (ts :: [*]). NTup ts -> Expr (Flatten ts), in an equation for ‘fstExpr’ at Strange.hs:26:10-22 ‘ts’ is a rigid type variable bound by a pattern with constructor: Tuple :: forall (ts :: [*]). NTup ts -> Expr (Flatten ts), in an equation for ‘fstExpr’ at Strange.hs:26:10-22 Expected type: NTup ts Actual type: NTup '[a, b] • In the pattern: P x y In the pattern: Tuple (P x y) In an equation for ‘fstExpr’: fstExpr (Tuple (P x y)) = (x, y) • Relevant bindings include fstExpr :: Expr (a, b) -> (Expr a, Expr b) (bound at Strange.hs:26:1) | 26 | fstExpr (Tuple (P x y)) = (x, y) | ^^^^^ It seems that providing a type signature causes GHC to forget the injectivity of Flatten (i.e (a, b) ~ Flatten ts implies ts ~ '[a, b]). Is this a bug, some limitation of pattern synonyms, or am I missing something? Thanks as always, Travis

2 2

Why not short out IND_STATICs in the GC?
by Ömer Sinan Ağacan 29 Apr '19

29 Apr '19

Hi Simon, I'm wondering why in the GC we don't short out IND_STATICs like we do in INDs and BLACKHOLEs. Is there a reason for that? In this code in evacuate(): case IND_STATIC: evacuate_static_object(IND_STATIC_LINK((StgClosure *)q), q); return; Why not do something like case IND_STATIC: q = ((StgIndStatic*)q)->indirectee; *p = q; goto loop; I actually tried it and it broke a lot of things, but I don't understand why. We basically turn this heap closure -> IND_STATIC -> heap closure into heap closure -> heap closure To me this should work, but for some reason it doesn't. Could you comment on why this doesn't work? Thanks, Ömer

2 1

Locations in the codegen where we assume pointers tagged with certain values?
by Ömer Sinan Ağacan 27 Apr '19

27 Apr '19

Hi all, I'm trying to find all places in the code generator where we assume that a pointer is tagged with a certain value. A generated code for this looks like this: mov 0x6(%rbx),%rax This moves payload[0] of the closure in %rbx to %rax, but it assumes that %rbx is tagged with 2 so it does 0x6(%rbx) instead of 0x8(%rbx). Anyone know where I should be looking at? Context: I'm implementing shorting out indirections in the concurrent collector. The code is quite similar to the current collector, except we do a cas() when updating the IND/BLACKHOLE pointer with the pointer to the indirectee. The problem is this causes all kinds of problems, in our debugging mostly caused by pointer misalignment. One concrete example of where this happens is we do mov 0x6(%rbx),%rax but the pointer in %rbx is actually tagged 3 instead of 2. The reason is I think we're breaking some invariants in the generated code where we assume certain tags from pointers (2 in the example above), but I couldn't find where in the code generator we do this. Thanks, Ömer

2 2

Gitlab down
by Ben Gamari 26 Apr '19

26 Apr '19

Due to an unfortunate mis-typing of the word "restart" gitlab.haskell.org is currently rebooting. I'll let you know when it's back up. Cheers, - Ben

1 0

Re: [ANNOUNCE] GHC 8.8.1-alpha1 is now available
by Ryan Scott 26 Apr '19

26 Apr '19

The 8.8 Migration Guide can be found here: https://gitlab.haskell.org/ghc/ghc/wikis/migration/8.8 Ryan S.

1 0

Moe Bot
by David Eichmann 26 Apr '19

26 Apr '19

Hello All, I've been working on Moe Bot recently who will quote commits that mention issues. When a commit is pushed to master, Moe will create a new comment on the referenced issue quoting the full commit message. This is for your convenience so you can avoid having to navigate off the page to see the full commit message. Unfortunately this has triggered a large number of notification emails as Moe works to quote existing commits. *You can safely ignore emails from Moe.* I've disabled him for now. Sorry for the disturbance this morning. David Eichmann -- David Eichmann, Haskell Consultant Well-Typed LLP, http://www.well-typed.com Registered in England & Wales, OC335890 118 Wymering Mansions, Wymering Road, London W9 2NF, England

2 1

Marge bot UX improvement suggestion
by Ömer Sinan Ağacan 26 Apr '19

26 Apr '19

I think it'd be useful if Marge listed commits that it's trying to merge in the description of the MR so that we could get a list of commits in the emails. Currently the emails just say "Marge Bot Barch MR - DO NOT TOUCH" with an empty body. Ömer

4 3