- ghc-devs - Haskell.org

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

RE: Puzzled by GHC.Types.LiftedRep
by Simon Peyton Jones 24 Apr '19

24 Apr '19

Try this paper<https://www.microsoft.com/en-us/research/publication/levity-polymorphism/> The function type constructor actually has type (->) :: forall (r1::RuntimeRep) (r2::RuntimeRep). TYPE r1 -> TYPE r2 -> TYPE LiftedRep But when it appears applied to two argument, thus ((->) r1 r2 t1 t2), we print it infix (t1 -> t2). So (-> 'GHC.Types.LiftedRep 'GHC.Types.LiftedRep thing thing) is the same as (thing -> thing). I cannot explain why it is being printed in that non-infix way, but your email doesn’t give enough context to know. I hope this helps a bit. Where did you look for information? I’d like to add pointers that would have been helpful to you. Simon From: Ranjit Jhala <jhala(a)cs.ucsd.edu> Sent: 24 April 2019 04:56 To: ghc-devs(a)haskell.org; Simon Peyton Jones <simonpj(a)microsoft.com> Subject: Puzzled by GHC.Types.LiftedRep Hi all, Consider the following program: ``` import Control.Arrow (second) import qualified Control.Monad.Trans.Reader as R myLocal :: (r -> r) -> R.ReaderT r m a -> R.ReaderT r m a myLocal = undefined foo :: (thing -> thing) -> R.ReaderT (d, thing) m a -> R.ReaderT (d, thing) m a foo arg = myLocal (second arg) ``` When compiled with GHC 8.6.4, I get the odd behavior that at the call `second arg`, the type of `arg` is just: thing -> thing but the *input* type of `second` (after applying the various type and dictionary parameters) is something that looks like while the *input* type of `second` (after the various type and dictionary applications etc.) is the mysterious (to me): (-> 'GHC.Types.LiftedRep 'GHC.Types.LiftedRep thing thing) Can someone explain or point me to some documentation or paper that describes what the above means? Specifically, how/why does GHC "equate" the two things above in order to consider the core well-formed? Many thanks in advance! - Ranjit.

1 0

[ANNOUNCE] GHC 8.6.5 is now available
by Ben Gamari 24 Apr '19

24 Apr '19

Hello everyone, The GHC team is proud to announce the release of GHC 8.6.5. The source distribution, binary distributions, and documentation are available at https://downloads.haskell.org/~ghc/8.6.5 Release notes are also available [1]. This release fixes a handful of issues with 8.6.4: - Binary distributions once again ship with Haddock documentation including syntax highlighted source of core libraries (#16445) - A build system issue where use of GCC with `-flto` broke `configure` was fixed (#16440) - An bug affecting Windows platforms wherein XMM register values could be mangled when entering STG has been fixed (#16514) - Several Windows packaging issues resulting from the recent CI rework. (#16408, #16398, #16516) Do note that due to linking issues (see #15934) profiling will be rather unreliable on Windows. This will be fixed in 8.8.1. As always, if anything looks amiss do let us know. Happy compiling! Cheers, - Ben [1] http://downloads.haskell.org/~ghc/8.6.5/docs/html/users_guide/8.6.5-notes.h…

2 1

build .so from boot libraries
by Németh Boldizsár 16 Apr '19

16 Apr '19

Hi, I'm trying to run compiler plugins on the source code of GHC itself. (Has anyone done this before?) Somehow this forces the loading of .so files of boot libraries (like libHSterminfo-0.4.1.3.so and libHSghc-boot-th-8.9.so) during GHC's compilation. The .so files are not built at this stage (only in later stages) by default. Is there an option to create dynamically linked libraries from the boot libraries in stage 0? BR, Boldizsár

2 1