August 2016 - ghc-devs

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 16 Aug '16

16 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

How to force -fPIC on package builds?
by Dominick Samperi 15 Aug '16

15 Aug '16

Hello, I am getting relocation errors when building an executable (specifically, the "H" executable -- part of haskellR) under Fedora Linux, and the message says to "recompile with -fPIC". The FAQ associated with H suggests that I switch to the gold linker (ld.gold) due to bugs in the default linker (ld.bfd), but this only changes the wording of the relocation error messages. I have tried several strategies for satisfying the -fPIC requirement: 1. In cabal files I insert cc-options: and ghc-options: lines including -fPIC 2. To the 'cabal install' command line I add: --ghc-option=-fPIC --hsc2hs-option=-cflag=-fPIC 3. When building ghc 8.0.1 from source I modify config.mk by including: CONF_CC_OPTS += -fPIC SRC_HSC2HS_OPTS += --cflag=-fPIC CONF_CC_OPTS_STAGE0 = -fno-stack-protector -fPIC [same for STAGE1 and STAGE2] All of this doesn't fix the problem, and the error messages still say "recompile with -fPIC". This may be a bug, but I'm not sure where. Any ideas? Thanks, Dominick

2 6