- ghc-devs - Haskell.org

New type of ($) operator in GHC 8.0 is problematic
by Christopher Allen 04 Feb '16

04 Feb '16

$ ghci :lGHCi, version 8.0.0.20160122: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/callen/.ghci Prelude> :t ($) ($) :: forall (w :: GHC.Types.Levity) a (b :: TYPE w). (a -> b) -> a -> b As someone that's working on a book for beginners/intermediates and that mentions ($) early'ish, this is pretty disconcerting. Particularly as we're not going to explain Levity or TYPE. Is this intentional? My only ~/.ghci flag is fno-warn-type-defaults. Apologies if this is a mix-up on my part. --- Chris

1 0

Re: Automatically deriving Generic for every algebraic data type
by Ryan Scott 04 Feb '16

04 Feb '16

I'm a pretty solid -1 on this idea. On a general level, I'm opposed to the idea of deriving typeclasses without the programmer opting in. Most typeclasses express operations that your datatype must support, and in the case of Generic(1), it mandates that users can convert between values of your datatype and an isomorphic representation type. As Oleg noted, this completely destroys encapsulation for datatypes whose constructors you don't want to export. Another issue is the nontrivial cost of automatic derivation. Typeclasses can be surprisingly expensive to derive. About a year ago, Reid Barton measured the amount of increase in code size that each derivable typeclass contributes [1], and Generic was far and away the most expensive one. There's also the issue that deriving Generic on large datatypes can drastically increase the amount of memory needed during compilation [2]. Yet another problem is that deriving Generic1 simply doesn't work for every datatype. Not only does deriving Generic1 not work with sophisticated language features (e.g., -XExistentialQuantification [3]) by design, but there are still a number of outstanding bugs that prevent legitimate Generic1 from being deriving automatically. For example, the following datatype: newtype Compose (f :: k1 -> *) (g :: k2 -> k1) (a :: k2) = Compose (f (g a)) chokes when attempting to derive Generic1 automatically [4]. You have to hack around this by using -XStandaloneDeriving with a programmer-specified instance context. One could imagine a compromise in which Generic(1) would not be derived for datatypes for which attempting to derive those classes yields an error. But I would argue that this is very undesirable, since programmers would just expect every datatype to work out of the box with Generic(1), only to find "Cannot find instance Generic1 Compose"-like errors when they try using Generic1 operations on datatypes that trip the bug mentioned in [4]. There are exceptions to the don't-derive-typeclasses-automatically rule, with Typeable being a notable example [5]. But deriving Typeable has the benefit that (1) it doesn't impose many requirements on your datatype (other than you can get a TypeRep for it), (2) it's cheap to derive (see the table in [1]), and (3) it works on literally every datatype. Ryan S. ----- [1] https://ghc.haskell.org/trac/ghc/ticket/9557#comment:8 [2] https://ghc.haskell.org/trac/ghc/ticket/5642 [3] https://ghc.haskell.org/trac/ghc/ticket/10514 [4] https://ghc.haskell.org/trac/ghc/ticket/10524#comment:16 [5] https://ghc.haskell.org/trac/ghc/ticket/8950

2 1

Automatically deriving Generic for every algebraic data type
by Wolfgang Jeltsch 04 Feb '16

04 Feb '16

Hi, if you do generic programming these days, you can use DeriveAnyClass to write code like the following (where Serializable is a class with a generic default implementation): > data Tree a = Leaf | Branch (Tree a) a (Tree a) > deriving (Generic, Serializable) It would be great, if you could just write the following instead: > data Tree a = Leaf | Branch (Tree a) a (Tree a) deriving Serializable This would correspond exactly to what you do when using standard Haskell deriving. It could be made possible by letting the compiler instantiate the Generic class automatically every time an algebraic data type is declared. A potential downside of this would be that programmers would not be able to define non-standard instances of Generics, but I actually cannot see that this is very useful anyhow. Any comments? All the best, Wolfgang

3 3

Specializing expressions beyond names?
by Conal Elliott 04 Feb '16

04 Feb '16

It seems to be the case that SPECIALIZE pragmas are syntactically restricted to type specializations of a *name* (identifier) rather than a general expression. Is my understanding correct here? If so, is there any reason for this restriction? I ask because I’m reifying Core code (into code that constructs a corresponding run-time representation for further processing), and I’m looking for a clean way to integrate that process with GHC, to support separate compilation and to avoid interfering with GHC’s regular flow. It occurred to me that I could enable separate compilation via a pragma of the form “{-# SPECIALIZE reify foo ∷ E t #-}” for some t, where E t is a reified form of values of type t. Type checking would infer the specialized type of foo, and the usual specialization phase would do its usual thing on that specialization, leaving “reify foo = reify specialized_foo”, and then the reification compiler plugin would transform the right-hand side, pushing the reify inward. Some reify calls may remain (e.g., due to polymorphism), triggering future rule applications. As much as possible of the fully-reified version would be factored out of the generated rule’s RHS for cheap reuse. Thanks, - Conal

2 3

CallStack naming
by Richard Eisenberg 03 Feb '16

03 Feb '16

Hi devs, I'm sure there's an easy answer to this, but I'm wondering: why is the CallStack feature implemented with implicit parameters instead of just a magical constraint? Whenever I use this feature, I don't want to have to enable -XImplicitParams and then make sure I get the name right. What would be wrong with, e.g., > undefined :: AppendsCallStack => a Seems simpler. Is it problems with a nullary class? Thanks, Richard

6 18

PrimRep constructor Vec
by Richard Eisenberg 03 Feb '16

03 Feb '16

Hi Geoff, I'm working on the fix for #11471, which involves interacting with the PrimRep type. (You don't need the ticket background to understand this question, though.) One of PrimRep's constructors is VecRep, which Simon tells me is your domain. The problem is that I can find nowhere in the source code where this constructor is used. I see several consumers, but no producers. Is this constructor now unused? Should I remove it? Thanks, Richard

3 3

Re: Adding a "release" setting in build.mk.sample (and some other build system questions)
by Harry . 03 Feb '16

03 Feb '16

> https://ghc.haskell.org/trac/ghc/wiki/MakingReleases#Makingthebinarybuilds > https://ghc.haskell.org/trac/ghc/wiki/Building/Using#Buildconfiguration So the mysterious SRC_HC_OPTS = -O -H64m which appears in every build flavour isn't used for the release build?

3 3

Re: [GHC] #11526: unsafeLookupStaticPtr should not live in IO
by Mathieu Boespflug 02 Feb '16

02 Feb '16

IMHO this dynamic linking thing is a red herring. In principle any function call becomes potentially impure given eg the ability to shadow symbols. In practice that's not something we do to programs. We could consider having two tables though: an initial tackle generated at compile time that will never change, and an aux table populated as new objects get linked in. Then programs can "opt in" to taking into account new objects loaded dynamically by reading (in IO) the aux table. Sent from my mobile. I'll have a look at the new material on the wiki shortly. It would be nice to close out the basic distributed story.

2 1

Best practices for merging?
by Geoffrey Mainland 02 Feb '16

02 Feb '16

I've been away from GHC for a while, and it's not clear to me what the best practices for merging are now. My usual git workflow is to work on a feature branch, get a nice clean set of patches, each of which implements a discrete bit of functionality, rebase onto master, and then merge with an empty merge commit, i..e, *not* fast-forward. This lets me look at the repo history and easily see where a feature branch landed and get a good idea of what changes it contains. I have used this approach in the past with GHC, e.g., SIMD support and typed TH. For smaller sets of changes, I might skip the merge commit, but I still break up my changes into discreet bits, which helps anyone reading the change set to see what's going on. It seems the current policy is to submit changes via Phab and then, after approval, squash everything into a single patch and apply it with arc. At least that is my reading of https://ghc.haskell.org/trac/ghc/wiki/Phabricator/Extras#Landingreviews. Is that what I should be doing? For feature branches, is that also what is advised? Thanks, Geoff

10 19

[ANNOUNCE] Glasgow Haskell Compiler 8.0.1, release candidate 1
by Ben Gamari 02 Feb '16

02 Feb '16

The GHC Team is very pleased to announce the first release candidate of the Glasgow Haskell Compiler 8.0.1 release. Source and binary distributions as well as the newly revised users guide can be found at http://downloads.haskell.org/~ghc/8.0.1-rc1/ This is the first in a series of release candidates which will allow us to get wider testing of the significant changes that have occurred since the 7.10 series. These include, * the TypeInType extension, which unifies types and kinds allowing for promotion of more Haskell constructs to the type-level * the introduction of type application in source programs * support for recursive superclass relationships * support for Applicative do notation * introduction of the DuplicateRecordFields language extension * a rewritten and substantially more thorough pattern match checker * the introduction of injective type classes * introduction of the Strict and StrictData language extensions, allowing modules to be compiled with strict-by-default evaluation of bindings * the ability to run the GHCi interpreter in a separate process, allowing a callstacks in GHCi, easier integration with tooling, and more and much more. Changes of this magnitude will invariably bring bugs. This release candidate in particular is known to suffer from a few significant issues which are being actively worked upon, * The new -XInjectiveTypeFamilies language extension will likely be renamed to -XTypeFamilyDependencies * #11120: Type representations are missing for some types and promoted constructors * #11334: Solving for Typeable (Proxy :: Proxy 'Compose) fails * #11276: Pattern checker performance can degrade significantly in presence of pattern matches with guards * #11405: Type-level skolem-escape check fails incorrectly * #11414: Use of -XStrict results in compiler abort * #11379: Instance solver fails to terminate * #11419: Haddock documentation is currently not included in the binary distributions (and hence is missing on downloads.haskell.org) * #11370: -Wredundant-constraints being included in -Wall breaks the three-release compatibility policy In the coming weeks we will continue to iterate on these issues. We will also look at Trac tickets marked with "highest" priority on the release status page [2]. If you have a ticket that you would like to see addressed that does not meet one of these criteria, please bring this to our attention. Likewise, if you encounter an issue please open a ticket if one does not already exist. Also note that we currently cannot offer 32-bit Windows builds due to breaking changing in a recent Windows 10 upgrade. We'll work to resolve this before the 8.0 release but please let us know if this poses a significant problem for you. Cheers, - Ben [1] https://cygwin.com/ml/cygwin/2015-12/msg00003.htm [2] https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-8.0.1

13 35