Compiler panic applying polymorphic functions to unboxed values

[benl]

Added by Jared

example () = do
    ub3 = primInt32U_neg $ 3#
    ()

Gives

cc1: warnings being treated as errors
./Foo.ddc.c: In function ‘Panic1_main’:
./Foo.ddc.c:39: error: passing argument 2 of ‘Data_Function__symDl’ makes
pointer from integer without a cast
./Foo.ddc.c:39: error: assignment makes integer from pointer without a cast
ddc: PANIC in Main.Invoke
        invokeSeaCompiler: compilation of C file failed.
            pathC = ./Panic1.ddc.c

Should detect this in core and give a nicer error message.

[erikd]

As for #178 (duplicate of this one) this should really be a type error because applying a polymorphic function to an unboxed value is never going to be correct.

[benl]

We should add a proper kind for unboxed types # after GHC.

However, it'd be nice if we can keep class instances like Num Int32#.

Maybe we want:

Kind of values:         ** 
Kind of boxed values:   *
Kind of unboxed values: #

class Num :: ** -> + 

We would allow numeric functions to be used with unboxed values provided we can resolve what instance is used at the point of use. Anytime we generalise a function with a class context, like

double :: forall (a :: *). Num a => a -> a

We lower the kind of the quantified variable from ** to *.

TODO: GHC includes the kinds ?? and ?, where one is the "argument kind" and one is the "result kind". Why was this? Will we need two versions of ** as well?

TODO: We already have [] (ki con box) as a kind for non-witness kinds. Is this the same as either ?? or ?.

TODO: I don't wan't to use the symbol ? as a kind because it looks to general. We have region effect and closures as well, and ** is just supposed to represent a (boxed or unboxed) value.