August 2018 - ghc-tickets

[GHC] #15538: GHC boot script can't handle Git origin not named origin
by GHC 19 Aug '18

19 Aug '18

#15538: GHC boot script can't handle Git origin not named origin -------------------------------------+------------------------------------- Reporter: ChaiTRex | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Build System | Version: Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Building GHC Unknown/Multiple | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- == Problem I ran the following to get the sources for GHC to build them: {{{ git clone -o ghc --recursive http://git.haskell.org/ghc.git }}} Note especially the `-o ghc` part, which uses the Git origin name `ghc` instead of the default `origin`. When a custom origin name is used, `./boot` fails: {{{ $ ./boot Traceback (most recent call last): File "./boot", line 193, in <module> check_for_url_rewrites() File "./boot", line 29, in check_for_url_rewrites subprocess.check_output('git config remote.origin.url'.split()).find(b'github.com') != -1 and \ File "/usr/lib/python3.5/subprocess.py", line 626, in check_output **kwargs).stdout File "/usr/lib/python3.5/subprocess.py", line 708, in run output=stdout, stderr=stderr) subprocess.CalledProcessError: Command '['git', 'config', 'remote.origin.url']' returned non-zero exit status 1 $ git config remote.origin.url $ echo $? 1 }}} == Solution To get the URL of the proper origin name, `git config branch.master.remote` can be used to get the origin name to use to get the URL: {{{ $ git config "remote.$( git config branch.master.remote ).url" http://git.haskell.org/ghc.git }}} == Workaround Rename the origin to `origin`: {{{ $ git remote rename "$( git config branch.master.remote )" origin $ ./boot Creating libraries/mtl/ghc.mk Creating libraries/unix/ghc.mk Creating libraries/text/ghc.mk ⋮ }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15538> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #15536: Unify unlifted pointer equality primitives
by GHC 19 Aug '18

19 Aug '18

#15536: Unify unlifted pointer equality primitives -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- We have a bunch of different primops to test pointer equality between various unlifted pointer types (`MutableArray#`, `MutVar#`, etc.). Now that we have the necessary type machinery, I believe we should be able to get away with just one: {{{#!hs unliftedPtrEquality# :: forall (a :: TYPE 'UnliftedRep). a -> a -> Int# }}} All the rest can then be defined as regular functions in `GHC.Exts` or some such. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15536> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #9441: Merge identical top-level expressions following simplification when it is safe to do so
by GHC 18 Aug '18

18 Aug '18

#9441: Merge identical top-level expressions following simplification when it is safe to do so -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- If I redefine {{{#!hs {-# INLINE reverse #-} reverse :: [a] -> [a] reverse xs = build $ \c n -> foldl (\a x -> x `c` a) n xs }}} and then write a couple test cases: {{{#!hs appRev xs ys = xs ++ reverse ys revAppRev xs ys = reverse xs ++ reverse ys }}} I end up getting some rather annoying code duplication (lots of stuff omitted from the following): {{{#!hs Rec { poly_go_r2v3 poly_go_r2v3 = \ @ a_a2nF ds_a2zc eta_Xl -> case ds_a2zc of _ { [] -> eta_Xl; : y_a2zh ys_a2zi -> poly_go_r2v3 ys_a2zi (: y_a2zh eta_Xl) } end Rec } reverse reverse = \ @ a_a2nF eta_B1 -> poly_go_r2v3 eta_B1 ([]) Rec { revAppRev2 revAppRev2 = \ @ a_a2y7 ds_a2zc eta_B1 -> case ds_a2zc of _ { [] -> eta_B1; : y_a2zh ys_a2zi -> revAppRev2 ys_a2zi (: y_a2zh eta_B1) } end Rec } Rec { revAppRev1 revAppRev1 = \ @ a_a2y7 ds_a2zc eta_B1 -> case ds_a2zc of _ { [] -> eta_B1; : y_a2zh ys_a2zi -> revAppRev1 ys_a2zi (: y_a2zh eta_B1) } end Rec } Rec { appRev1 appRev1 = \ @ a_a2xE ds_a2zc eta_B1 -> case ds_a2zc of _ { [] -> eta_B1; : y_a2zh ys_a2zi -> appRev1 ys_a2zi (: y_a2zh eta_B1) } end Rec } }}} The `reverse` function was inlined three times. In each case, there was no fusion, so `build` was inlined and the resulting copy of the `reverse` worker lifted to the top level. It would seem to me that once simplification is complete, it should be safe to merge all these copies into one. They are all `Rec {\ ... -> ...}` forms, so I don't think this has any potential to introduce undesirable sharing. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9441> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #15050: ScopedTypeVariables could allow more programs
by GHC 18 Aug '18

18 Aug '18

#15050: ScopedTypeVariables could allow more programs -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider {{{ data P a = P data T1 a where MkT1 :: forall a. P a -> T1 a MkT2 :: forall a. P a -> T1 (a,a) MkT3 :: forall a b. b ~ Int => P a -> P b -> T1 a MkT4 :: forall a b. P a -> P b -> T1 a MkT5 :: forall a b c. b ~ c => P a -> P b -> P c -> T1 a }}} I can write this function {{{ foo :: T1 (Int, Int) -> () foo (MkT1 (P::P (Int,Int))) = () foo (MkT2 (P::P x)) = (() :: x ~ Int => ()) foo (MkT3 P (P::P Int)) = () foo (MkT4 P (P::P b)) = () foo (MkT5 P (P::P b) (P::P b)) = () }}} but this these two equations fail {{{ foo (MkT1 (P::P (Int,x))) = (() :: x ~ Int => ()) foo (MkT1 (P::P x)) = (() :: x ~ (Int,Int) => ()) }}} I am especially surprised by the second one, given that the very similar equation with `MkT2` works. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15050> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 25

[GHC] #15537: Panic when building Crucible
by GHC 18 Aug '18

18 Aug '18

#15537: Panic when building Crucible -------------------------------------+------------------------------------- Reporter: siddharthist | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I've encountered a panic, which GHC has asked me to report: {{{ [19 of 21] Compiling Lang.Crucible.LLVM.Translation ( src/Lang/Crucible/LLVM/Translation.hs, dist/build/Lang/Crucible/LLVM/Translation.p_o ) <no location info>: error: ghc: panic! (the 'impossible' happened) (GHC version 8.4.3 for x86_64-unknown-linux): isUnliftedType r_a4Zsg :: TYPE rep_a4Zsf Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1150:37 in ghc:Outputable pprPanic, called at compiler/types/Type.hs:1939:10 in ghc:Type Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} This was when compiling [https://github.com/GaloisInc/crucible/tree/master /crucible-llvm crucible-llvm] revision 186mfb7wlz with GHC 8.4.3. I'm building in Nix with a sandbox, so this should be easily reproducible. The Nix files are available here: https://github.com/siddharthist/galois- haskell-nix/tree/ghc-bug. Just run nix-build -A haskellPackages.crucible- llvm. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15537> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #15490: Can Template Haskell and RULES be combined?
by GHC 17 Aug '18

17 Aug '18

#15490: Can Template Haskell and RULES be combined? -------------------------------------+------------------------------------- Reporter: ChaiTRex | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- It would be nice if there was something like this: {{{#!hs {-# RULES "(literal*)" forall n. (n*) = $( makeOptimizedMultiplication [|| n ||] ) #-} }}} where `makeOptimizedMultiplication` is a Template Haskell function that, if `n` is an integer literal, produces an optimized multiplication function for that literal. However, that code above gives a `VarE` corresponding to the `n` in the quoter rather than the AST of the `n` that's actually being matched by the rewrite rule, so I can't get a `LitE` that way. This sort of thing would come in very handy for a large fixed-width integer type, because I don't think GHC and LLVM will know that standard fixed-width integer optimizations apply to it. For example, with a `Word65536` type, multiplying blindly at runtime by the literal `1099511627777` requires a lot of extra work. At the very least, all 65536 bits of that literal have to be read and dealt with pretty blindly. However, at compile time, the compiler can take the time to figure out that `(1099511627777*)` can be replaced with the much, much lighter `(\x -> shiftL x 40 + x)` (and not only that, but if `Word65536`s are stored in a byte array, 1 byte evenly divides the shift amount of 40 bits, which can be exploited to speed things up greatly). With appropriate `RULES` and Template Haskell functions, the compiler gains the ability to apply lots of fixed-width integer optimizations. Since the above sort of code doesn't work, is there some other way to do this that I don't know about? If not, can the feature be added? ---- The only downside I can think of is that the user of the `Word65536` type might not knowingly be expecting Template Haskell to be at work since they didn't use any splices or quoters and might not have even included `{-# LANGUAGE TemplateHaskell #-}` in their code, so perhaps some easy method of consenting to the application of TH-based rewrites might be in order. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15490> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #15532: Relaxing Levity-Polymorphic Binder Check for Lifted vs Unlifted pointers
by GHC 17 Aug '18

17 Aug '18

#15532: Relaxing Levity-Polymorphic Binder Check for Lifted vs Unlifted pointers -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple LevityPolymorphism | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: 14917 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I'm going to define two terms that I will use with these meanings for the remainder of this post. 1. Runtime-Rep Polymorphism: full polymorphism in the runtime representation 2. Levity Polymorphism: polymorphism dealing with lifted vs unlifted types that are definitely represented by pointers. GHC's levity polymorphism has the restriction that runtime-rep-polymorphic binders are not allowed. A comment David made recently on https://github.com/haskell/primitive/issues/198 got me thinking about the possibility of relaxing this restriction when it comes to dealing with a function with levity-polymorphic (not runtime-rep-polymorphic) binders. GHC's runtime already appears to allow doing this. AndrasKovacs writes on https://www.reddit.com/r/haskell/comments/6v9rmg/an_unified_array_interface… that he is able to store both lifted and unlifted values inside of the same `Array#` (pointing out as well that their primop implementations are identical) without crashing the GC. As further evidence that we can, roughly speaking, use lifted and unlifted values in the same places, I threw together a little experiment: {{{ {-# LANGUAGE MagicHash #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE TypeInType #-} import Data.Primitive import Data.Primitive.UnliftedArray import GHC.Types import GHC.Exts main :: IO () main = do a@(Array myArr) <- newArray 1 ("foo" :: String) >>= unsafeFreezeArray UnliftedArray myArrArr <- newUnliftedArray 1 a >>= unsafeFreezeUnliftedArray putStrLn (myFunc show (2 :: Integer)) putStrLn (myFunc2 (\x -> show (Array x)) myArr) putStrLn (myBigFunc (+1) show show (2 :: Integer)) putStrLn (myBigFunc2 (\x -> array# (indexUnliftedArray (UnliftedArray x) 0 :: Array String)) (\x -> show (Array x)) (\x -> show (UnliftedArray x :: UnliftedArray (Array String))) myArrArr) {-# NOINLINE myFunc #-} myFunc :: (a -> String) -> a -> String myFunc f a = let x = f a in x ++ x myFunc2 :: forall (a :: TYPE 'UnliftedRep). (a -> String) -> a -> String myFunc2 = unsafeCoerce# myFunc {-# NOINLINE myBigFunc #-} myBigFunc :: (a -> b) -> (b -> String) -> (a -> String) -> a -> String myBigFunc f g h a = let y = f a x = g y in x ++ x ++ h a myBigFunc2 :: forall (a :: TYPE 'UnliftedRep) (b :: TYPE 'UnliftedRep). (a -> b) -> (b -> String) -> (a -> String) -> a -> String myBigFunc2 = unsafeCoerce# myBigFunc }}} The compiles (surprisingly without a core lint error) and runs fine. So, here's the idea. We start with David's suggested change to `RuntimeRep`: {{{ data RuntimeRep = PtrRep Levity | ... data Levity = Lifted | Unlifted }}} And then we change the check that disallows runtime-rep polymorphism in binding positions to accept levity polymorphism in binding positions (but continuing to reject runtime-rep polymorphism). For example, the two examples in the above code snippet would be rewritten as: {{{ myFunc :: forall (v :: Levity) (a :: TYPE ('PtrRep v)). (a -> String) -> a -> String myFunc = ... -- same implementation myBigFunc :: forall (v :: Levity) (w :: Levity) (a :: TYPE ('PtrRep v)) (b :: TYPE ('PtrRep w)). (a -> b) -> (b -> String) -> (a -> String) -> a -> String myBigFunc = ... -- same implementation }}} Again, GHC's runtime seems to already allow this. It's just the type system that's missing support for it. The only weird thing I can think of that comes up is that you cannot use bang patterns on a levity-polymorphic argument since unlifted values cannot be entered. I think it is possible to go a little further still. Fields of data types could be levity polymorphic: {{{ data List (a :: TYPE ('PtrRep v)) = Cons a (List a) | Nil map :: forall (v :: Levity) (w :: Levity) (a :: TYPE ('PtrRep v)) (b :: TYPE ('PtrRep w)). (a -> b) -> List a -> List b }}} Again, bang patterns would need to be forbidden on such fields. This doesn't get us everything sought out in https://ghc.haskell.org/trac/ghc/wiki/UnliftedDataTypes, but it's kind of a half-way point that requires no changes to GHC's runtime and no changes to code generation. I think the whole thing can be handled in the type checker. Other potential application: `Array#` and `ArrayArray#` (and nearly all functions that operate on them) could be consolidated into a single type, reducing the number of duplicated primop implementations in GHC. Of course this would all need to be a GHC proposal, but I wanted to first solicit some feedback here on initial draft of the idea. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15532> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #15524: Performance regression when using the GHC API to evaluate code compared to 8.4
by GHC 17 Aug '18

17 Aug '18

#15524: Performance regression when using the GHC API to evaluate code compared to 8.4 -------------------------------------+------------------------------------- Reporter: vaibhavsagar | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.6.1-beta1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I've been in the process of updating IHaskell to support GHC 8.6 and the test suite has become agonisingly slow as compared to GHC 8.4 and below. I've been able to work around this by using `--enable-executable-dynamic` as suggested by `christiaanb` on `#ghc`but I thought this was worth reporting as a bug. I am using `ghc-8.6.1-alpha2` so it's possible that this has been fixed in `beta1`. To reproduce this on a Linux installation with Nix: 1. `git clone https://github.com/gibiansky/IHaskell --branch support- ghc-8-6 repro` 2. `cd repro` 3. Comment out `--enable-executable-dynamic` in `release-8.6.nix` 4. `nix-build release-8.6.nix` -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15524> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #15531: CApiFFI generates bad prototypes for pointers of `Foreign.C` types
by GHC 17 Aug '18

17 Aug '18

#15531: CApiFFI generates bad prototypes for pointers of `Foreign.C` types -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider the example {{{#!hs {-# LANGUAGE CApiFFI #-} module Foo where import Foreign.Ptr import Foreign.C foreign import capi unsafe "foo.h fn1" c_fn1 :: Char -> IO Char foreign import capi unsafe "foo.h fn2" c_fn2 :: Ptr Char -> IO (Ptr Char) foreign import capi unsafe "foo.h fn3" c_fn3 :: Ptr (Ptr Char) -> IO (Ptr (Ptr Char)) foreign import capi unsafe "foo.h fn4" c_fn4 :: CChar -> IO CChar foreign import capi unsafe "foo.h fn5" c_fn5 :: Ptr CChar -> IO (Ptr CChar) foreign import capi unsafe "foo.h fn6" c_fn6 :: Ptr (Ptr CChar) -> IO (Ptr (Ptr CChar)) foreign import capi unsafe "foo.h fn7" c_fn7 :: CUChar -> CSChar -> CShort -> CUShort -> CInt -> CUInt -> CLong -> CULong -> CSize -> IO () foreign import capi unsafe "foo.h fn8" c_fn8 :: Ptr CUChar -> Ptr CSChar -> Ptr CShort -> Ptr CUShort -> Ptr CInt -> Ptr CUInt -> Ptr CLong -> Ptr CULong -> Ptr CSize -> IO () }}} which creates various wrappers; this generates the C wrapper {{{#!c #define IN_STG_CODE 0 #include "Rts.h" #include "Stg.h" #ifdef __cplusplus extern "C" { #endif #include "foo.h" void ghczuwrapperZC0ZCmainZCFooZCfn8(void* a1, void* a2, void* a3, void* a4, void* a5, void* a6, void* a7, void* a8, void* a9) {fn8(a1, a2, a3, a4, a5, a6, a7, a8, a9);} #include "foo.h" void ghczuwrapperZC1ZCmainZCFooZCfn7(HsWord8 a1, HsInt8 a2, HsInt16 a3, HsWord16 a4, HsInt32 a5, HsWord32 a6, HsInt64 a7, HsWord64 a8, HsWord64 a9) {fn7(a1, a2, a3, a4, a5, a6, a7, a8, a9);} #include "foo.h" void** ghczuwrapperZC2ZCmainZCFooZCfn6(void** a1) {return fn6(a1);} #include "foo.h" void* ghczuwrapperZC3ZCmainZCFooZCfn5(void* a1) {return fn5(a1);} #include "foo.h" HsInt8 ghczuwrapperZC4ZCmainZCFooZCfn4(HsInt8 a1) {return fn4(a1);} #include "foo.h" HsChar** ghczuwrapperZC5ZCmainZCFooZCfn3(HsChar** a1) {return fn3(a1);} #include "foo.h" HsChar* ghczuwrapperZC6ZCmainZCFooZCfn2(HsChar* a1) {return fn2(a1);} #include "foo.h" HsChar ghczuwrapperZC7ZCmainZCFooZCfn1(HsChar a1) {return fn1(a1);} #ifdef __cplusplus } #endif }}} Specifically, the wrappers for `c_fn4`, `c_fn5` and `c_fn8` are wrong. This is quite a serious bug as it renders `CApiFFI` unusable for matching with C prototypes, as modern C compilers will refuse to coerce a pointer `void**` into an argument to a function expecting a `char**`. One concrete example is e.g. {{{#!hs -- int getfilecon(const char *path, char **con); foreign import capi safe "selinux/selinux.h getfilecon" c_getfilecon' :: CString -> Ptr CString -> IO CInt }}} which even though properly declared (NB: `type CString = Ptr CChar`), when compiled would fail because of this bug: {{{ tmpdir/ghc31009_0/ghc_2.c: In function ‘ghczuwrapperZC0ZCmainZCBarZCgetfilecon’: tmpdir/ghc31009_0/ghc_2.c:8:92: error: warning: passing argument 2 of ‘getfilecon’ from incompatible pointer type [-Wincompatible-pointer-types] HsInt32 ghczuwrapperZC0ZCmainZCBarZCgetfilecon(void* a1, void** a2) {return getfilecon(a1, a2);} ^ | 8 | HsInt32 ghczuwrapperZC0ZCmainZCBarZCgetfilecon(void* a1, void** a2) {return getfilecon(a1, a2);} | ^ In file included from tmpdir/ghc31009_0/ghc_2.c:7:0: error: /usr/include/selinux/selinux.h:101:12: error: note: expected ‘char **’ but argument is of type ‘void **’ extern int getfilecon(const char *path, char ** con); ^ | 101 | extern int getfilecon(const char *path, char ** con); | ^ }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15531> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #15493: Elide empty dictionaries
by GHC 17 Aug '18

17 Aug '18

#15493: Elide empty dictionaries -------------------------------------+------------------------------------- Reporter: mnoonan | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Suppose you define a type class `C` with no methods, and use it as a constraint on a function `f :: C => Foo`. GHC's generated Core for `f` currently passes an empty dictionary for `C`. With optimizations, it seems to be true that at use sites, calls to `f` will be replaced with calls to an inner function that skips the typeclass dictionary. But can I count on this optimization always working? Would it possible to get a guarantee that the `C =>` constraint will have no run-time overhead, by dropping it entirely from the generated Core? Or is there a subtlety that prevents this from being sound? For context, I would like to implicitly pass compile-time evidence that various properties hold (e.g. such-and-such a list is non-empty), while retaining a guarantee that the evidence will have no run-time cost. Like this: {{{ newtype Named a name = Named a class Fact p -- Ideally, we'd have a guarantee that the following function -- compiles to exactly the same code as `Prelude.head` head :: Fact (IsCons xs) => (a `Named` xs) -> a head xs = Prelude.head (coerce xs) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15493> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4