5

I'm running up against what looks like invalid code generated by Happy. The problem boils down to GHC not inferring a polykinded type signature for a function. Here is an example of this:

{-# Language MagicHash #-}

f x = ()

main = pure (f 1#)

Since GHC is inferring f :: a -> () where a :: *, this fails with 

 • Couldn't match a lifted type with an unlifted type
   When matching the kind of ‘GHC.Prim.Int#’
 • In the first argument of ‘f’, namely ‘1#’
   In the first argument of ‘pure’, namely ‘(f 1#)’
   In the expression: pure (f 1#)

Are there any language pragmas I could just turn on to get this code to compile? I know I could in theory just add type signatures but, as this is code generated by Happy which I'd prefer not to have to manually modify anything.

Alec
  • 31,829
  • 7
  • 67
  • 114
  • 1
    This seems relevant: https://stackoverflow.com/a/35320729/180286. Basically a function can't be polymorphic over kinds, unless you really want to, and only in GHC 8+ – Fyodor Soikin Aug 02 '17 at 23:45
  • 3
    If Happy generates code which doesn't compile in this way, it is probably a bug in Happy (perhaps one which can be worked around!). Can you put together a minimal Happy example which produces such code? I don't think GHC ever infers a kind other than `*` for a polytype. – user2407038 Aug 03 '17 at 00:47
  • 1
    @user2407038 Although my question still stands, this particular Happy bug is easily fixed. Basically any generated code that uses `happyMonad2Reduce` and was not generated with `-a` will have this problem for the `nt :: Int#` variable (which is not used without `-a`, hence the type inference issues). I'm currently fighting some nastier Happy issues, so filing an issue for _this_ is going on the back burner. :) – Alec Aug 03 '17 at 01:03
  • 1
    @Alec Thanks for the explanation, I see you are already aware of the problem/solution higher up in the toolchain. This question is interesting in a much broader context than Happy, but unfortunately I don't think it has a solution (other than writing a type signature). Best of luck! – user2407038 Aug 03 '17 at 01:09
  • 3
    Inference or no, the argument to `f` can't have a polykinded (specifically, levity-polymorphic) type. `x` is a variable with the type that would be levity-polymorphic, and no variables can have such types. So you'd need GHC to infer a *monomorphic* type here. My guess is that whereas the type checker can delay class-polymorphic code to apply the monomorphism restriction, it has no mechanism for doing so with (fundamentally) levity-polymorphic code. – dfeuer Aug 03 '17 at 04:37

1 Answers1

2

As hinted at by @dfeuer, this is impossible. In the worst case, GHC would have to look for usages of a given function across the whole project in order to infer the levity of an argument.

This was reported as a bug in Happy and has since been fixed.

Alec
  • 31,829
  • 7
  • 67
  • 114