March 2016 - ghc-devs

Table of contents
by Simon Peyton Jones 25 Mar '16

25 Mar '16

Could the table of contents for the GHC user manual have one more level showing? Or just all levels? http://downloads.haskell.org/~ghc/master/users-guide/ I often search for things I can’t find Thanks Simon

2 1

How to prevent GHC (API) from breaking large constants into multiple top-level bindings
by Christiaan Baaij 24 Mar '16

24 Mar '16

My situation is the following, given the code: > {-# LANGUAGE GADTs, DataKinds, TypeOperators, KindSignatures #-} > module GConst where > > import GHC.TypeLits > > data Vec :: Nat -> * -> * > where > Nil :: Vec 0 a > Cons :: a -> Vec n a -> Vec (n+1) a > > infixr `Cons` > > c :: Vec 5 Int > c = 1 `Cons` 2 `Cons` 3 `Cons` 4 `Cons` 5 `Cons` Nil The output of the desugarer, 'ghc -O -fforce-recomp -fno-full-laziness -ddump-ds -dsuppress-all GConst.hs', is: > c = > ($WCons > (I# 1) > (($WCons > (I# 2) > (($WCons > (I# 3) > (($WCons (I# 4) (($WCons (I# 5) ($WNil)) `cast` ...)) `cast` ...)) > `cast` ...)) > `cast` ...)) > `cast` ... Where the constant 'c' is a single large constant. However, when I look at the output of the simplifier, 'ghc -O -fforce-recomp -fno-full-laziness -ddump-simpl -dsuppress-all GConst.hs', I see this: > c10 > c10 = I# 1 > > c9 > c9 = I# 2 > > c8 > c8 = I# 3 > > c7 > c7 = I# 4 > > c6 > c6 = I# 5 > > c5 > c5 = Cons @~ <0 + 1>_N c6 ($WNil) > > c4 > c4 = Cons @~ <1 + 1>_N c7 (c5 `cast` ...) > > c3 > c3 = Cons @~ <2 + 1>_N c8 (c4 `cast` ...) > > c2 > c2 = Cons @~ <3 + 1>_N c9 (c3 `cast` ...) > > c1 > c1 = Cons @~ <4 + 1>_N c10 (c2 `cast` ...) > > c > c = c1 `cast` ... The single constant is completely taken apart into multiple top-level bindings. I haven't given it too much thought, but I assume there are good reasons to take large constants aparts, and break them into individual top-level bindings. At least when your target is a normal CPU. Now, I'm a GHC API user, and I convert Haskell programs to digital circuits. For my use case, breaking up constants into smaller top-level bindings has completely no performance benefits at all. Actually, my compiler _inlines_ all those top-level bindings again to create a single large constant. When working with large constants, my compiler is actually taking an disproportionately large amount of time of doing the inverse of what the GHC simplifier did. I want to keep using the GHC simplifier, because it contains many optimisations that are usefull for my specific use-case. So my question is: how can I stop the GHC simplifier from breaking up large constants into smaller top-level bindings? As you could see from the example, this "breaking-apart-constants" is not due to the FullLaziness transform, as I explicitly disabled it. If this "breaking-apart-constants" part is not (currently) controllable by a flag, would it be possible to add such a flag? I'm happy to work on a patch myself if someone could tell where about in the simplifier I would have to make some changes. Thanks, Christiaan

2 2

Harbormaster MIA?
by Joachim Breitner 24 Mar '16

24 Mar '16

[Re-ending to the list, sorry Austin for the unnecessary private mail.] Hi, I’m looking forward to see what Harbormaster thinks of https://phabricator.haskell.org/D2014 but it seems that no build has been scheduled. What is wrong? Greetings, Joachim -- Joachim “nomeata” Breitner mail(a)joachim-breitner.de • https://www.joachim-breitner.de/ XMPP: nomeata(a)joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F Debian Developer: nomeata(a)debian.org

2 1

RE: [Diffusion] [Build Failed] rGHC7e7407977243: Comment fix
by Simon Peyton Jones 24 Mar '16

24 Mar '16

Phab seems to be failing immediately Simon | -----Original Message----- | From: noreply(a)phabricator.haskell.org | [mailto:noreply@phabricator.haskell.org] | Sent: 24 March 2016 09:51 | To: Simon Peyton Jones <simonpj(a)microsoft.com> | Subject: [Diffusion] [Build Failed] rGHC7e7407977243: Comment fix | | Harbormaster failed to build B8834: rGHC7e7407977243: Comment fix! | | BRANCHES | master | | USERS | simonpj (Author) | GHC - Type checker/inferencer (Auditor) | | COMMIT | https://phabricator.haskell.org/rGHC7e7407977243 | | EMAIL PREFERENCES | https://phabricator.haskell.org/settings/panel/emailpreferences/ | | To: simonpj, GHC - Type checker/inferencer, Harbormaster

2 1

Support for colors in ghci
by Никита Нежевский 23 Mar '16

23 Mar '16

Hello I'm newcomer in GHC. I'd like to realize native support for colors in ghci (this feature was described in https://ghc.haskell.org/trac/ghc/ticket/10073 ). Is it possible to realize inside ghci? If possible i'd like to understand how to start implementation and how it might look in ghci? Best regards, Nikita Nezhevskii.

2 1

lookupRdrNameInModuleForPlugins with constructors
by Conal Elliott 23 Mar '16

23 Mar '16

I'm trying to construct a dictionary in a GHC plugin. I'm stuck on finding the constructor for the dictionary. When I use `-ddump-simpl` on the module that defines the class, I see "Circat.Rep.C:HasRep". To try finding that constructor, I say > lookupRdrNameInModuleForPlugins hsc_env > (mkModuleName "Circat.Rep") (mkVarUnqual "C:HasRep") However, I keep getting `Nothing` as a result. (Same without the "C:".) I've also had this same difficulty when looking up constructors for algebraic data types and when looking up TyCons. For regular value Ids, lookup succeeds. What am I missing? Thanks, - Conal

3 6

VisibleTypeApplication and AllowAmbiguousTypes
by Andrew Martin 21 Mar '16

21 Mar '16

I'm posting this because Richard said it would be the best place to raise this issue. I know it's a little bit late in the GHC8 development process, but I would like to get the idea out there. To my knowledge, in GHC8, turning on VisibleTypeApplication will also turn on AllowAmbiguousTypes. I think that a better behavior for most end users would be to not have this happen. I need AllowAmbiguousTypes turned on in modules where I want to declare functions that are presently uncalled. At a call site though, I only need VisibleTypeApplication, not both extensions. The only reason I bring this up is because having AllowAmbiguousTypes on is usually bad. It makes it possible to write functions that don't work, but you don't learn that until you get to the call site. If I write libraries that require VisibleTypeAppliaction to call certain functions, I don't want users accidentally ending up turning on AllowAmbiguousTypes in their own code. -- -Andrew Thaddeus Martin

5 6

Could we promote unlifted tuples?
by David Feuer 21 Mar '16

21 Mar '16

At present, currying and uncurrying at the type level doesn't seem to work terribly well. In particular, the kinds (a, b) -> c and a -> b -> c aren't really isomorphic, because (a, b) can be stuck. This makes some things (like expressing Atkey-style indexed functors in terms of McBride-style ones) rather awkward, and difficult or impossible to really get quite right. The thought came to me that maybe we could allow unlifted tuples to be promoted. Then something of the kind (# a, b #) would unconditionally unify with '(# a, b #). The restrictions on how values of unlifted tuple types can be used would presumably translate directly to restrictions on how types of unlifted tuple kind can be used. David Feuer

2 1

Issue using StrictData
by Andrés Sicard-Ramírez 19 Mar '16

19 Mar '16

Hi, I know this isn't a convenient issue report because the "test case" isn't easily reproducible. Since I don't understand the issue, I don't know how to create a smaller test case, sorry. My OS is Ubuntu 12-04 (64 bits) and I'm using the following programs: Agda master branch on commit https://github.com/agda/agda/commit/181a954a40b137c8deb1df801a8ee55fdbc19116 GHC ghc-8.0 branch on commit https://git.haskell.org/ghc.git/commit/a96933017470d03a1c9414c9c90dfd5c0f09… $ cabal --version cabal-install version 1.23.0.0 compiled using version 1.23.1.0 of the Cabal library (compiled with GHC 7.10.3) $ alex --version Alex version 3.1.7, (c) 2003 Chris Dornan and Simon Marlow $ happy --version Happy Version 1.19.5 Copyright (c) 1993-1996 Andy Gill, Simon Marlow (c) 1997-2005 Simon Marlow After adding `extensions: StrictData` to Agda.cabal, I'm getting the following errors: $ cabal install ... Installing library in /home/asr/.cabal/lib/x86_64-linux-ghc-8.0.0.20160316/Agda-2.5.0-8eDdWzYvIFd4CKBTUUP6kU Installing executable(s) in /home/asr/.cabal/bin Generating Agda library interface files... agda: Internal Happy error CallStack (from HasCallStack): error, called at templates/GenericTemplate.hs:288:17 in Agda-2.5.0-8eDdWzYvIFd4CKBTUUP6kU:Agda.Syntax.Parser.Parser WARNING: Failed to typecheck Agda.Primitive! agda: Internal Happy error CallStack (from HasCallStack): error, called at templates/GenericTemplate.hs:288:17 in Agda-2.5.0-8eDdWzYvIFd4CKBTUUP6kU:Agda.Syntax.Parser.Parser WARNING: Failed to typecheck Agda.Builtin.Bool! agda: Internal Happy error CallStack (from HasCallStack): error, called at templates/GenericTemplate.hs:288:17 in Agda-2.5.0-8eDdWzYvIFd4CKBTUUP6kU:Agda.Syntax.Parser.Parser WARNING: Failed to typecheck Agda.Builtin.Char! agda: Internal Happy error CallStack (from HasCallStack): error, called at templates/GenericTemplate.hs:288:17 in Agda-2.5.0-8eDdWzYvIFd4CKBTUUP6kU:Agda.Syntax.Parser.Parser WARNING: Failed to typecheck Agda.Builtin.Coinduction! agda: Internal Happy error CallStack (from HasCallStack): error, called at templates/GenericTemplate.hs:288:17 in Agda-2.5.0-8eDdWzYvIFd4CKBTUUP6kU:Agda.Syntax.Parser.Parser WARNING: Failed to typecheck Agda.Builtin.Equality! agda: Internal Happy error CallStack (from HasCallStack): error, called at templates/GenericTemplate.hs:288:17 in Agda-2.5.0-8eDdWzYvIFd4CKBTUUP6kU:Agda.Syntax.Parser.Parser WARNING: Failed to typecheck Agda.Builtin.Float! agda: Internal Happy error CallStack (from HasCallStack): error, called at templates/GenericTemplate.hs:288:17 in Agda-2.5.0-8eDdWzYvIFd4CKBTUUP6kU:Agda.Syntax.Parser.Parser WARNING: Failed to typecheck Agda.Builtin.FromNat! agda: Internal Happy error CallStack (from HasCallStack): error, called at templates/GenericTemplate.hs:288:17 in Agda-2.5.0-8eDdWzYvIFd4CKBTUUP6kU:Agda.Syntax.Parser.Parser WARNING: Failed to typecheck Agda.Builtin.FromNeg! agda: Internal Happy error CallStack (from HasCallStack): error, called at templates/GenericTemplate.hs:288:17 in Agda-2.5.0-8eDdWzYvIFd4CKBTUUP6kU:Agda.Syntax.Parser.Parser WARNING: Failed to typecheck Agda.Builtin.FromString! agda: Internal Happy error CallStack (from HasCallStack): error, called at templates/GenericTemplate.hs:288:17 in Agda-2.5.0-8eDdWzYvIFd4CKBTUUP6kU:Agda.Syntax.Parser.Parser WARNING: Failed to typecheck Agda.Builtin.IO! agda: Internal Happy error CallStack (from HasCallStack): error, called at templates/GenericTemplate.hs:288:17 in Agda-2.5.0-8eDdWzYvIFd4CKBTUUP6kU:Agda.Syntax.Parser.Parser WARNING: Failed to typecheck Agda.Builtin.Int! agda: Internal Happy error CallStack (from HasCallStack): error, called at templates/GenericTemplate.hs:288:17 in Agda-2.5.0-8eDdWzYvIFd4CKBTUUP6kU:Agda.Syntax.Parser.Parser WARNING: Failed to typecheck Agda.Builtin.List! agda: Internal Happy error CallStack (from HasCallStack): error, called at templates/GenericTemplate.hs:288:17 in Agda-2.5.0-8eDdWzYvIFd4CKBTUUP6kU:Agda.Syntax.Parser.Parser WARNING: Failed to typecheck Agda.Builtin.Nat! agda: Internal Happy error CallStack (from HasCallStack): error, called at templates/GenericTemplate.hs:288:17 in Agda-2.5.0-8eDdWzYvIFd4CKBTUUP6kU:Agda.Syntax.Parser.Parser WARNING: Failed to typecheck Agda.Builtin.Reflection! agda: Internal Happy error CallStack (from HasCallStack): error, called at templates/GenericTemplate.hs:288:17 in Agda-2.5.0-8eDdWzYvIFd4CKBTUUP6kU:Agda.Syntax.Parser.Parser WARNING: Failed to typecheck Agda.Builtin.Size! agda: Internal Happy error CallStack (from HasCallStack): error, called at templates/GenericTemplate.hs:288:17 in Agda-2.5.0-8eDdWzYvIFd4CKBTUUP6kU:Agda.Syntax.Parser.Parser WARNING: Failed to typecheck Agda.Builtin.Strict! agda: Internal Happy error CallStack (from HasCallStack): error, called at templates/GenericTemplate.hs:288:17 in Agda-2.5.0-8eDdWzYvIFd4CKBTUUP6kU:Agda.Syntax.Parser.Parser WARNING: Failed to typecheck Agda.Builtin.String! agda: Internal Happy error CallStack (from HasCallStack): error, called at templates/GenericTemplate.hs:288:17 in Agda-2.5.0-8eDdWzYvIFd4CKBTUUP6kU:Agda.Syntax.Parser.Parser WARNING: Failed to typecheck Agda.Builtin.TrustMe! agda: Internal Happy error CallStack (from HasCallStack): error, called at templates/GenericTemplate.hs:288:17 in Agda-2.5.0-8eDdWzYvIFd4CKBTUUP6kU:Agda.Syntax.Parser.Parser WARNING: Failed to typecheck Agda.Builtin.Unit! Registering Agda-2.5.0... cabal: Leaving directory '.' Installed Agda-2.5.0 Best, -- Andrés

2 2

Updatable, single entry, one-short thunks and lambda
by Joachim Breitner 17 Mar '16

17 Mar '16

Dear list, in the literature, the code and the comments, I often find these notions: * updatable * single-entry * one-shot applied to thunks, functions, closures and lambda expressions on various levels I have the impression that these are indeed plain synonyms (resp. antinyms) when it comes to thunks and other closures, and indicate whether a dynamic instance of this closure is going to be entered once or more than once, while "one-shot", when applied to a lambda expression (or, by extension function argument), indicates that this lambda expression is _called_ at most once for every _evaluation_ of it. Is that about right, or are there more pitfalls around? Greetings, Joachim -- Joachim “nomeata” Breitner mail(a)joachim-breitner.de • https://www.joachim-breitner.de/ XMPP: nomeata(a)joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F Debian Developer: nomeata(a)debian.org

2 2