September 2017 - ghc-devs

Re: Why isn't this Typeable?
by Richard Eisenberg 25 Sep '17

25 Sep '17

I think we're a long way off from supporting Typeable for higher-kinded types, so I wouldn't worry about that dark, spider-ridden corner. Richard > On Sep 25, 2017, at 3:00 PM, David Feuer <david(a)well-typed.com> wrote: > > No. What led me down this path is that I was thinking about whether we could simplify the representation and reduce the TCB. The as-yet-incomplete ideas I had (largely based on the concept of using a constructor name as a singletons-style defunctionalization symbol) seem difficult to adapt to the generalization I describe, so I wanted to check first how much that matters. > > > David Feuer > Well-Typed, LLP > > -------- Original message -------- > From: Richard Eisenberg <rae(a)cs.brynmawr.edu> > Date: 9/25/17 2:42 PM (GMT-05:00) > To: David Feuer <david(a)well-typed.com> > Cc: Ben Gamari <ben(a)smart-cactus.org>, ghc-devs(a)haskell.org > Subject: Re: Why isn't this Typeable? > > I suppose this is conceivable, but it would complicate the representation and solver for TypeReps considerably. Do you have a real use case? > > Richard > > > On Sep 25, 2017, at 2:28 PM, David Feuer <david(a)well-typed.com> wrote: > > > > My example wasn't quite the one I intended (although I think it should > > work as well, and it's simpler). Here's the sort of example I really intended: > > > > data Bar :: forall (j :: forall k. k -> Maybe k) (a :: Type). Proxy (j a) -> Type > > > > I would expect > > > > Bar :: Proxy ('Just Int) -> Type > > > > or, to abuse notation a bit, > > > > Bar @'Just @Int > > > > to be Typeable. What I'm really suggesting is that we should distinguish between things that are typeable and > > things that can be decomposed into typeable components. We already make a limited distinction > > here. For example, we have > > > > 'Just :: forall a. a -> Maybe a > > > > 'Just itself cannot be Typeable, but once it's applied to a kind variable, it is Typeable. > > 'Just @Int is Typeable even though that (kind) application cannot be broken with App. Similarly, I'd expect > > Foo 'Just to be Typeable even though that (type) application cannot be broken with App (or Fun). > > > > Putting things in terms of fingerprints, we can offer type-indexed fingerprints > > > > newtype Finger a = Finger Fingerprint > > > > for anything we can fingerprint. Is there any difficulty fingerprinting types like Foo 'Just and > > Bar @'Just @Int? Fingerprints are useful for lots of applications where decomposition isn't > > necessary. > > > > On Sunday, September 24, 2017 1:16:37 PM EDT Richard Eisenberg wrote: > >> The problem is that to get Typeable (Foo 'Just), we need Typeable 'Just. However, the kind parameter for Typeable 'Just would be (forall a. a -> Maybe a), making the full constraint Typable (forall a. a -> Maybe a) 'Just. And saying that would be impredicative. In other contexts, 'Just *can* be Typeable, but it's 'Just invisibly instantiated at some monotype for `a`. > >> > >> So I think that this boils down to impredicativity and that the implementation is doing the right thing here. > >> > >> Richard > >> > >>> On Sep 24, 2017, at 5:45 AM, David Feuer <david(a)well-typed.com> wrote: > >>> > >>> data Foo :: (forall a. a -> Maybe a) -> Type > >>> > >>> Neither Foo nor Foo 'Just is Typeable. There seems to be a certain sense to excluding Foo proper, because it can't be decomposed with Fun. But why not Foo 'Just? Is there a fundamental reason, or is that largely an implementation artifact? > >>> > >>> David Feuer > >>> Well-Typed, LLP > >>> _______________________________________________ > >>> ghc-devs mailing list > >>> ghc-devs(a)haskell.org > >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > >> > > > > >

1 0

Re: Why isn't this Typeable?
by David Feuer 25 Sep '17

25 Sep '17

No. What led me down this path is that I was thinking about whether we could simplify the representation and reduce the TCB. The as-yet-incomplete ideas I had (largely based on the concept of using a constructor name as a singletons-style defunctionalization symbol) seem difficult to adapt to the generalization I describe, so I wanted to check first how much that matters. David FeuerWell-Typed, LLP -------- Original message --------From: Richard Eisenberg <rae(a)cs.brynmawr.edu> Date: 9/25/17 2:42 PM (GMT-05:00) To: David Feuer <david(a)well-typed.com> Cc: Ben Gamari <ben(a)smart-cactus.org>, ghc-devs(a)haskell.org Subject: Re: Why isn't this Typeable? I suppose this is conceivable, but it would complicate the representation and solver for TypeReps considerably. Do you have a real use case? Richard > On Sep 25, 2017, at 2:28 PM, David Feuer <david(a)well-typed.com> wrote: > > My example wasn't quite the one I intended (although I think it should > work as well, and it's simpler). Here's the sort of example I really intended: > > data Bar :: forall (j :: forall k. k -> Maybe k) (a :: Type). Proxy (j a) -> Type > > I would expect > > Bar :: Proxy ('Just Int) -> Type > > or, to abuse notation a bit, > > Bar @'Just @Int > > to be Typeable. What I'm really suggesting is that we should distinguish between things that are typeable and > things that can be decomposed into typeable components. We already make a limited distinction > here. For example, we have > > 'Just :: forall a. a -> Maybe a > > 'Just itself cannot be Typeable, but once it's applied to a kind variable, it is Typeable. > 'Just @Int is Typeable even though that (kind) application cannot be broken with App. Similarly, I'd expect > Foo 'Just to be Typeable even though that (type) application cannot be broken with App (or Fun). > > Putting things in terms of fingerprints, we can offer type-indexed fingerprints > > newtype Finger a = Finger Fingerprint > > for anything we can fingerprint. Is there any difficulty fingerprinting types like Foo 'Just and > Bar @'Just @Int? Fingerprints are useful for lots of applications where decomposition isn't > necessary. > > On Sunday, September 24, 2017 1:16:37 PM EDT Richard Eisenberg wrote: >> The problem is that to get Typeable (Foo 'Just), we need Typeable 'Just. However, the kind parameter for Typeable 'Just would be (forall a. a -> Maybe a), making the full constraint Typable (forall a. a -> Maybe a) 'Just. And saying that would be impredicative. In other contexts, 'Just *can* be Typeable, but it's 'Just invisibly instantiated at some monotype for `a`. >> >> So I think that this boils down to impredicativity and that the implementation is doing the right thing here. >> >> Richard >> >>> On Sep 24, 2017, at 5:45 AM, David Feuer <david(a)well-typed.com> wrote: >>> >>> data Foo :: (forall a. a -> Maybe a) -> Type >>> >>> Neither Foo nor Foo 'Just is Typeable. There seems to be a certain sense to excluding Foo proper, because it can't be decomposed with Fun. But why not Foo 'Just? Is there a fundamental reason, or is that largely an implementation artifact? >>> >>> David Feuer >>> Well-Typed, LLP >>> _______________________________________________ >>> ghc-devs mailing list >>> ghc-devs(a)haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> > >

1 0

Why isn't this Typeable?
by David Feuer 25 Sep '17

25 Sep '17

data Foo :: (forall a. a -> Maybe a) -> Type Neither Foo nor Foo 'Just is Typeable. There seems to be a certain sense to excluding Foo proper, because it can't be decomposed with Fun. But why not Foo 'Just? Is there a fundamental reason, or is that largely an implementation artifact? David FeuerWell-Typed, LLP

2 3

Re: RTS changes affect runtime when they shouldn’t
by David Feuer 24 Sep '17

24 Sep '17

I think changes to the RTS, code generator, and general heap layout are exactly where we *do* want to worry about these very low-level details. Changes in type checking, desugaring, core-to-core, etc., probably are not, because it's just too hard to tease out the relationship between what they do and what instructions are emitted in the end. David FeuerWell-Typed, LLP -------- Original message --------From: Sven Panne <svenpanne(a)gmail.com> Date: 9/24/17 2:00 PM (GMT-05:00) To: Joachim Breitner <mail(a)joachim-breitner.de> Cc: ghc-devs(a)haskell.org Subject: Re: RTS changes affect runtime when they shouldn’t 2017-09-23 21:06 GMT+02:00 Joachim Breitner <mail(a)joachim-breitner.de>: > what I want to do is to reliably catch regressions. The main question is: Which kind of regressions do you want to catch? Do you care about runtime as experienced by the user? Measure the runtime. Do you care abou code size? Measure the code size. etc. etc. Measuring things like the number of fetched instructions as an indicator for the experienced runtime is basically a useless exercise, unless you do this on ancient RISC processors, where each instruction takes a fixed number of cycles. > What are the odds that a change to the Haskell compiler (in particular to > Core2Core > transformations) will cause a significant increase in runtime without a > significant increase in instruction count? > (Honest question, not rhetoric). > The odds are actually quite high, especially when you define "significant" as "changing a few percent" (which we do!). Just a few examples from current CPUs: * If branch prediction has not enough information to do this better, it assumes that backward branches are taken (think: loops) and forward branches are not taken (so you should put "exceptional" code out of the common, straight-line code). If by some innocent looking change the code layout changes, you can easily get a very measurable difference in runtime even if the number of executed instructions stays exactly the same. * Even if the number of instructions changes only a tiny bit, it could be the case that it is just enough to make caching much worse and/or make the loop stream detector fail to detect a loop. There are lots of other scenarios, so in a nutshell: Measure what you really care about, not something you think might be related to that. As already mentioned in another reply, "perf" can give you very detailed hints about how good your program uses the pipeline, caches, branch prediction etc. Perhaps the performance dashboard should really collect these, too, this would remove a lot of guesswork.

1 0

Re: Why isn't this Typeable?
by David Feuer 24 Sep '17

24 Sep '17

I don't see why Typeable (Foo 'Just) requires that. I'd expect to get back a TrTyCon, not a TrApp. Some modifications to the structure of TrTyCon might be required. David FeuerWell-Typed, LLP -------- Original message --------From: Ryan Scott <ryan.gl.scott(a)gmail.com> Date: 9/24/17 10:08 AM (GMT-05:00) To: ghc-devs(a)haskell.org Subject: Re: Why isn't this Typeable? Trying to conclude Typeable Foo (or, if expanded with -fprint-explicit-kinds, Typeable ((forall a. a -> Maybe a) -> Type) Foo) is beyond GHC's capabilities at the moment, as that would require impredicative polymorphism. This problem has arose in other contexts too—see Trac #13895 [1] for one example. I don't think you can conclude Typeable (Foo 'Just) either, since that requires concluding both Typeable Foo and Typeable 'Just, so you ultimately run into the same problem. While there an in-the-works plan to allow a limited form of impredicativity through explicit use of visible type application [2], my fear is that that wouldn't be enough to address the problem you've encountered, since there's no way to visibly apply @((forall a. a -> Maybe a) -> Type) to Typeable at the moment. To accomplish this, you would need visible kind application [3]. Ryan S. ----- [1] https://ghc.haskell.org/trac/ghc/ticket/13895 [2] https://ghc.haskell.org/trac/ghc/ticket/11319#comment:11 [3] https://ghc.haskell.org/trac/ghc/ticket/12045 _______________________________________________ ghc-devs mailing list ghc-devs(a)haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

1 0

Re: Why isn't this Typeable?
by Ryan Scott 24 Sep '17

24 Sep '17

Trying to conclude Typeable Foo (or, if expanded with -fprint-explicit-kinds, Typeable ((forall a. a -> Maybe a) -> Type) Foo) is beyond GHC's capabilities at the moment, as that would require impredicative polymorphism. This problem has arose in other contexts too—see Trac #13895 [1] for one example. I don't think you can conclude Typeable (Foo 'Just) either, since that requires concluding both Typeable Foo and Typeable 'Just, so you ultimately run into the same problem. While there an in-the-works plan to allow a limited form of impredicativity through explicit use of visible type application [2], my fear is that that wouldn't be enough to address the problem you've encountered, since there's no way to visibly apply @((forall a. a -> Maybe a) -> Type) to Typeable at the moment. To accomplish this, you would need visible kind application [3]. Ryan S. ----- [1] https://ghc.haskell.org/trac/ghc/ticket/13895 [2] https://ghc.haskell.org/trac/ghc/ticket/11319#comment:11 [3] https://ghc.haskell.org/trac/ghc/ticket/12045

1 0

Ignoring ANN Module "HLint: ..."
by Moritz Angermann 24 Sep '17

24 Sep '17

Hi *, can we detect annotations like `{-# ANN module "HLint: ignore Reduce duplication" #-}` easily? Right now this will result (without -fexternal-interpreter or a stage2 compiler) in Ignoring ANN annotation, because this is a stage-1 compiler without -fexternal-interpreter or doesn't support GHCi However, I do not see why this should require the external interpreter at all. This looks to me more like an informational comment? Cheers, Moritz

2 3

The Curious Case of T6084 -or- Register Confusion with LLVM
by Moritz Angermann 21 Sep '17

21 Sep '17

Hi *, TLDR: The LLVM backend might confuse floating registers in GHC. # Demo (Ticket #14251) Let Demo.hs be the following short program (a minor modification from T6084): ``` {-# LANGUAGE MagicHash, BangPatterns #-} module Main where import GHC.Exts {-# NOINLINE f #-} f :: (Int# -> Float# -> Double# -> Float# -> Double# -> String) -> String f g = g 3# 4.0# 5.0## 6.0# 6.9## ++ " World!" {-# NOINLINE q #-} q :: Int# -> Float# -> Double# -> Float# -> Double# -> String q i j k l m = "Hello " ++ show (F# l) ++ " " ++ show (D# m) main = putStrLn (f $ q) ``` What happens if we compile them with the NCG and LLVM? $ ghc -fasm -fforce-recomp Demo.hs -O2 -o Demo-ncg && ./Demo-ncg Hello 6.0 6.9 World! $ ghc -fllvm -fforce-recomp Demo.hs -O2 -o Demo-llvm && ./Demo-llvm Hello 4.0 5.0 World! # Discussion What is happening here? The LLVM backend passes the registers in arguments, which are then mapped to registers via the GHC calling convention we added to LLVM. As the LLVM backend takes off from Cmm, we produce function that always hold the always live registers (on x86_64 these are: Base, Sp, Hp, R1, R2, R3, R4, R5, R6, SpLim) and appends those registers that are live throughout the function call: in the case of `q` this is one Float and one Double register. Let’s assume these are F3 and D4. Thus the function signature we generate looks like: ghccc void @q(i64*, i64*, i64*, i64, i64, i64, i64, i64, i64, i64, float, double) And expect the passed arguments to represent the following registers: base, sp, hp, r1, r2, r3, r4, r5, r6, spLim, f3, d4 as we found that f1 and d1 are not live. Yet, when we call `q` in the form of `g` in the body of `f`. We will pass it 14 arguments instead of 12. To make this “typecheck” in LLVM, we @q' = bitcast @q to (i64*, i64*, i64*, i64, i64, i64, i64, i64, i64, i64, float, double, float, double) and call @q’(base, sp, hp, r1, r2, r3, r4, r5, r6, spLim, f1, d2, f3, d4). at this point, we now assign f3 <- f1 and d4 <- d2; while silently ignoring the passed arguments f3 and d4. (This is where my llvmng backend fell over, as it does not bitcast function signatures but tries to unify them.) # Solution? Initially, Ben and I though we could simply always pass all registers as arguments in LLVM and call it a day with the downside of create more verbose but correct code. As I found out, that comes with a few complications. For some reason, all active stg registers for my machine give me Base, Sp, Hp, R1, R2, R3, R4, R5, R6, SpLim, F1, D1, F2, D2, F3, D3, XMM1,XMM2,XMM3,XMM4,XMM5,XMM6, YMM1,YMM2,YMM3,YMM4,YMM5,YMM6, ZMM1,ZMM2,ZMM3,ZMM4,ZMM5,ZMM6 I should not have the YMM*, and ZMM* registers as I don’t have any AVX nor AVX512; that looks like only a patch away. However we try to optimize our register, such that we can pass up to six doubles or six floats or any combination of both if needed in registers, without having to allocate them on the stack, by assuming overlapping registers (See Note [Overlapping global registers]). And as such a full function signature in LLVM would as opposed to one that’s based on the “live” registers as we have right now, would consist of 12 float/double registers, and LLVM only maps 6. My current idea is to, pass only the explicit F1,D1,…,F3,D3 and try to disable the register overlapping for LLVM. This would probably force more floating values to be stack allocated rather than passed via registers, but would likely guarantee that the registers match up. The other option I can think of is to define some viertual generic floating registers in the llvm code gen: V1,…,V6 and then perform something like F1 <- V1 as float D1 <- V1 as double in the body of the function, while trying to use the `live` information at the call site to decide which of F1 or D1 to pass as V1. Ideas? Cheers, Moritz

4 6

[PATCH] Enable DTrace support on FreeBSD for dynamically linked RTS
by raichoo 19 Sep '17

19 Sep '17

Hi, I've played around a little bit and came up with a little proof-of-concept patch to enable DTrace support in FreeBSD. I've only managed to get it to work for the dynamically linked RTS. It would be great if someone could take a look at this so this can get possibly merged. :) Kind regards, raichoo

2 3

ANN: Overlay Hackage Package Index for GHC HEAD
by Herbert Valerio Riedel 19 Sep '17

19 Sep '17

Hi GHC devs, A long-standing common problem when testing/dogfooding GHC HEAD is that at some point during the development cycle more and more packages from Hackage will run into build failures. Obviously, constantly nagging upstream maintainers to release quickfixes for unreleased GHC HEAD snapshots which will likely break again a few weeks later (as things are generally in flux until freeze comes into effect) does not scale and only introduces a latency/coordination bottleneck, and on top of it ultimately results in spamming the primary Hackage Package index with releases (which has non-negligible negative impact/costs of its own on the Hackage infrastructure, and thus ought to be minimised). OTOH, we need the ability to easily test, debug, profile, and prototype changes to GHC HEAD while things are still in motion, and case in point, if you try to e.g. build `pandoc` with GHC HEAD today, you'll currently run into a dozen or so of packages not building with GHC HEAD. To this end, I've finally found time to work on a side-project (related to matrix.hackage.haskell.org) which implements a scheme tailored to `cabal new-build`, which is inspired by how Eta copes with a very related issue (they rely on it for stable versions of the compiler); i.e., they maintain a set of patches at https://github.com/typelead/eta-hackage/tree/master/patches which fix up existing Hackage packages to work with the Eta compiler. And this gave me the idea to use a similar scheme for GHC HEAD: https://github.com/hvr/head.hackage/tree/master/patches This folder already contains several of patches (which mostly originate from Ryan, Ben and myself) to packages which I needed to patch in order to build popular Hackage packages & tools. The main difference is how those patches are applied; Eta uses a modified `cabal` which they renamed to `etlas` which is checks availability of .patch & .cabal files in the GitHub repo linked above; Whereas for GHC HEAD with `cabal new-build` a different scheme makes more sense: we simply generate an add-on Hackage repo, and use the existing `cabal` facilities (e.g. multi-repo support or the nix-style package store which makes sure that unofficially patched packages don't contaminate "normal" install-plans, etc.) to opt into the opt-in Hackage repo containing fixed up packages. I've tried to describe how to use the HEAD.hackage add-on repo in the README at https://github.com/hvr/head.hackage#how-to-use And finally, here's a practical example of how you can use it to build e.g. the `pandoc` executable with GHC HEAD (can easily be adapted to build your project of choice; please refer to http://cabal.readthedocs.io/en/latest/nix-local-build-overview.html to learn more about how to describe your project via `cabal.project` files): 0.) This assumes you have a recent cabal 2.1 snapshot built from Git 1.) create & `cd` into a new work-folder 2.) invoke `head.hackage.sh update` to update the HEAD.hackage index cache 3.) invoke `head.hackage.sh init` to create an initial `cabal.project` configuration which locally activates the HEAD.hackage overlay repo 4.) If needed, edit the cabal.project file and change where GHC HEAD can be found (the script currently assumes GHC HEAD is installed from my Ubuntu PPA), e.g. with-compiler: /home/hvr/src/ghc-dev/inplace/bin/ghc-stage2 or you can add something like `optional-packages: deps/*/*.cabal` to have cabal pick up package source-trees unpacked in the deps/ folder, or you can inject ghc-options, relax upper bounds via `allow-newer: *:base` etc (please refer to the cabal user guide) 5.) Create a `dummy.cabal` file (in future we will have `cabal new-install` or other facilities, but for now we use this workaround): --8<---------------cut here---------------start------------->8--- name: dummy version: 0 build-type: Simple cabal-version: >=2.0 library default-language: Haskell2010 -- library components you want cabal to solve & build for -- and become accessible via .ghc.environment files and/or -- `cabal new-repl` build-depends: base, lens -- executable components you want cabal to build build-tool-depends: pandoc:pandoc --8<---------------cut here---------------end--------------->8--- 6.) invoke `cabal new-build` 7.) If everything works, you'll find the `pandoc:pandoc` executable somewhere in your ~/.cabal/store/ghc-8.3.*/ folder (you can use http://hackage.haskell.org/package/cabal-plan to conveniently list the location via `cabal-plan list-bins`) 8.) As for libraries, you can either use `cabal new-repl` or you can leverage GHC's package environment files: `cabal new-build` will have generated a file like .ghc.environment.x86_64-linux-8.3.20170913 which brings into scope all transitive dependencies of `build-depends: base, lens` Now all you need to do is simply call ghc-stage2 --make MyTestProg.hs to compile a program against those libs, or start up GHCi via ghc-stage2 --interactive and you'll be thrown into that package environment. I hope you find this useful Cheers, Herbert

6 5