- ghc-devs - Haskell.org

Landing Backpack in HEAD
by Edward Z. Yang 19 Aug '16

19 Aug '16

Hello friends, I'm hoping to land Backpack (the patch is two years in the making now!) for GHC 8.2, even though 8.2 is intended to be a stabilization and performance release. In this email, I will make the case that the Backpack patch is relatively self-contained and will not affect non-Backpack users, and explain how you might be affected by the patch. The most recent patchset can be found at https://github.com/ezyang/ghc/tree/ghc-backpack ; look for "The Backpack patch" in the commit log, since I plan on squashing these commits before committing. OK, here is what is in the patchset that affects non-Backpack users: - The primary, overarching change is that there is now a distinction between "semantic" and "identity" modules. This solves a problem with hsig files: suppose you have A.hsig which defines data T in package p. The resulting A.hi is most accurately identified as p[A=<A>]:A; however, the Name for T should be <A>.T, not p[A=<A>]:A.T. The former is an identity module (it *identifies* interfaces), whereas the latter is a semantic module (it is what is used in names). Without Backpack, these two identities are always the same. There are a number of places in the existing codepaths where we have to distinguish between the two concepts (sometimes you want semantic, sometimes you want identity); we DEFAULT to the identity module but I fix a few cases where semantic modules were desired instead. - UnitId is generalized to also record how a component is instantiated (a mapping from module names to modules.) Without Backpack this is blank and equivalent to the existing UnitId. - Packages has been refactored to also handle Backpack `-unit-id` flags, since we have to do some extra work to determine what inherited signatures merge where. - The patch REVERTS all of the old support we had for hsig files; -sig-of is no more. spinda had mentioned that Liquid Haskell used this in some cases, and I'm looking at supporting *just* their particular use-case. - A new driver mode --backpack, which process test.bkp files. This mode is used PURELY for testing, and end users are not supposed to use it. These all live in their own modules (BkpSyn, DriverBkp) except for some modest, convenient extensions to the lexer and parser to parse multiple modules at once. The patch also comes with rewritten typechecking support for hsig files, and instantiating indefinite packages on the fly, but these are all standalone pieces of functionality which are not tied to any existing compiler infrastructure. Thanks, Edward

3 2

Request for feedback: deriving strategies syntax
by Ryan Scott 18 Aug '16

18 Aug '16

I'm pursuing a fix to Trac #10598 [1], an issue in which GHC users do not have fine-grained control over which strategy to use when deriving an instance, especially when multiple extensions like -XGeneralizedNewtypeDeriving and -XDeriveAnyClass are enabled simultaneously. I have a working patch up at [2] which would fix the issue, but there's still a lingering question of what the right syntax is to use here. I want to make sure I get this right, so I'm requesting input from the community. To condense the conversation in [1], there are three means by which you can derive an instance in GHC today: 1. -XGeneralizedNewtypeDeriving 2. -XDeriveAnyClass 3. GHC's builtin algorithms (which are used for deriving Eq, Show, Functor, Generic, Data, etc.) The problem is that it's sometimes hard to know which of the three will kick in when you say `deriving C`. To resolve this ambiguity, I want to introduce the -XDerivingStrategies extension, where a user can explicitly request which of the above ways to derive an instance. Here are some of the previously proposed syntaxes for this feature, with their perceived pros and cons: ----- Pragmas * Examples: - newtype T a = T a deriving ({-# BUILTIN #-} Eq, {-# GND #-} Ord, {-# DAC #-} Read, Show) - deriving {-# BUILTIN #-} instance Functor T * Pros: - Backwards compatible - Requires no changes to Template Haskell * Cons: - Unlike other pragmas, these ones can affect the semantics of a program ----- Type synonyms * Examples: - newtype T a = T a deriving (Builtin Eq, GND Ord, DAC Read, Show) - deriving instance Builtin (Functor T) * Pros: - Requires no Template Haskell or parser changes, just some magic in the typechecker - Backwards compatible (back to GHC 7.6) * Cons: - Some developers objected to the idea of imbuing type synonyms with magical properties ----- Multiple deriving clauses, plus new keywords * Examples: - newtype T a = T a deriving Show deriving builtin instance (Eq, Foldable) deriving newtype instance Ord deriving anyclass instance Read - deriving builtin instance Functor T * Pros: - Doesn't suffer from the same semantic issues as the other suggestions - (Arguably) the most straightforward-looking syntax * Cons: - Requires breaking changes to Template Haskell - Changes the parser and syntax significantly Several GHC devs objected to the first two of the above suggestions in [1], so I chose to implement the "Multiple deriving clauses, plus new keywords" option in [2]. However, I'd appreciate further discussion on the above options, which one you prefer, and if you have other suggestions for syntax to use. Ryan S. ----- [1] https://ghc.haskell.org/trac/ghc/ticket/10598 [2] https://phabricator.haskell.org/D2280

15 29

Suggesting RankNTypes for ill-formed types
by Karolina Drobnik 18 Aug '16

18 Aug '16

Hello everyone, I am working on my first ticket (#11669, linked below) and I have some doubts after a little bit of hacking. There was a hint that an error message should be changed from the one suggesting RankNTypes to ExplicitForall. In my opinion it would be quite confusing for the user, especially where the type is ill-formed. A plain parse error should be shown here. It is clear that it should be done in such a way after turning on one of the extensions, but what about the situation where proposed fix (suggesting RankNTypes/ExplicitForall) won't work? We should be able to distinguish ill-formed type from the correct one, even before the extension activation. To be honest - I don't know how to do it. Additionally, I am not sure if we can assume that an user wants to use arbitrary rank (which implies ExplicitForall) or just a forall keyword. I am for the second one, but it is just my assumption. And the last minor thing - a type formed in this way also rises an error suggesting using RankNTypes (as we know that wouldn't solve the problem): f :: a. -> Int f = undefined Maybe we could treat it as a typo (simple parse error) and propose an extension activation only when forall was parsed earlier? That could be tricky. I'd appreciate some thoughts on this issue because I felt a bit lost after digging around the parser. Best regards, Karolina --------------------------------------------------------- #11669 - https://ghc.haskell.org/trac/ghc/ticket/11669

4 3

Broken Build due to T1969
by Matthew Pickering 17 Aug '16

17 Aug '16

Hi all, https://phabricator.haskell.org/rGHC773e3aadac4bbee9a0173ebc90ffdc9458a2a3a9 broke the build by re-enabling the test T1969 The ticket tracking this is: https://ghc.haskell.org/trac/ghc/ticket/12437 Omer: Is it best to revert this patch and mark the test broken again? Matt

2 5

Back from move
by Ben Gamari 17 Aug '16

17 Aug '16

Hello everyone! If I have seemed quiet over the last few weeks it is because I was in the middle of a trans-Atlantic move to the United States. Needless to say, I am now somewhat settled again and will be working through my mail backlog over the next day or so. If you have sent something that you'd like a response from me on and I don't reply within the next day don't hesitate to ping me. Cheers, - Ben

1 0

ghc command line arguments parsing
by Harendra Kumar 17 Aug '16

17 Aug '16

Hi, ghc accepts a flag and its argument as a single quoted or escaped argument as well. For example all of the following are equivalent: ghc -package foo ghc "-package foo" ghc -package\ foo Is this by design or accidental? This has a nice side effect to make passing ghc arguments via rughc simple. For example runghc "-package foo" or runghc -package\ foo will pass "-package foo" to ghc. The alternative and documented way to achieve the same effect is runghc -package --ghc-arg=foo which is not that convenient. My question is - can we rely on this way of parsing? If it is not by design, does it make sense to legalize and therefore document this? -harendra

1 0

Question about initializing the run-time system
by Iavor Diatchki 17 Aug '16

17 Aug '16

Hello, GHC's user guide says that the run-time system cannot re-initialize itself, after it was shut-down (i.e., you can't call `hs_init` after calling `hs_exit`). Could anyone shed some light on why that is? -Iavor

2 1

RdrName and decorations
by Alan & Kim Zimmerman 16 Aug '16

16 Aug '16

Hi all At the moment I am working through ghc-exactprint, adding a feature to add standard API annotations to any constructed AST so that it can be (pretty)-printed. One of the major headaches is the decorations on a RdrName. What I mean by this is that an item appearing in the AST as a RdrName may have parens or backquotes around it, and may have a preceding keyword out of [forall, pattern, type]. I am slowly teasing out the contextual requirements to determine these, but it seems that they should be captured directly in the AST already. And not as API Annotations. So the question is, does it make sense to do this? Does it belong in the OccName or the RdrName if so? Alan

3 2

Behavior of GHC_PACKAGE_PATH
by Harendra Kumar 16 Aug '16

16 Aug '16

Hi, As per the GHC manual (https://downloads.haskell. org/~ghc/master/users-guide/packages.html#the-ghc-package- path-environment-variable), packages which come earlier in the GHC_PACKAGE_PATH supersede the ones which come later. But that does not seem to be the case always. I am dealing with a case where I have multiple versions of a package in different databases. I am passing the list of package dbs via GHC_PACKAGE_PATH and ghc is picking the one which comes later. I expect it to pick the one which comes earlier in the path. In one case the package being picked from a package db which comes later is a newer version which makes me wonder if GHC always prefers a newer version. In another case both the versions are same but still GHC is using the one which come later in the package path. Are there any undocumented factors into play here? None of the packages is broken (as reported by ghc-pkg check). See https://github.com/commercialhaskell/stack/issues/1957#issuecomment- 239655912 for more details on where it is coming from. Thanks, Harendra

1 0

Re: [GHC] #8516: Add (->) representation and the Invariant class to GHC.Generics
by Nicolas Frisby 15 Aug '16

15 Aug '16

"While were in there", it occurred to me that one `coerce` per constructor argument ideally ought to suffice. On Mon, Aug 15, 2016, 07:17 GHC <ghc-devs(a)haskell.org> wrote: > #8516: Add (->) representation and the Invariant class to GHC.Generics > -------------------------------------+------------------------------------- > Reporter: nfrisby | Owner: > Type: feature request | Status: new > Priority: low | Milestone: > Component: Compiler (Type | Version: 7.7 > checker) | > Resolution: | Keywords: Generics > Operating System: Unknown/Multiple | Architecture: > | Unknown/Multiple > Type of failure: None/Unknown | Test Case: > Blocked By: | Blocking: > Related Tickets: | Differential Rev(s): > Wiki Page: | > -------------------------------------+------------------------------------- > > Comment (by RyanGlScott): > > And as it turns out, goldfire has a separate ticket (#8177) for the > proposed idea of being able to give explicit role signatures to type > families, which might make the potential regression in > [https://ghc.haskell.org/trac/ghc/ticket/8516#comment:7 this comment] not > an actual regression. See my comment > [https://ghc.haskell.org/trac/ghc/ticket/8177#comment:31 here]. > > -- > Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8516#comment:11> > GHC <http://www.haskell.org/ghc/> > The Glasgow Haskell Compiler >

1 0