Kinds of type synonym arguments

Edward Kmett ekmett at
Mon Dec 21 09:10:27 UTC 2015

I brought up the subject of allowing newtypes in kind # (or even in any
kind that ends in * or # after a chain of ->'s to get more powerful
Coercible instances) at ICFP this year and Simon seemed to think it'd be a
pretty straightforward modification to the typechecker.

I confess, he's likely waiting for me to actually sit down and give the
idea a nice writeup. ;)

This would be good for many things, especially when it comes to improving
the type safety of various custom c-- tricks.


On Sun, Dec 20, 2015 at 2:14 PM, Ömer Sinan Ağacan <omeragacan at>

> I have another related question: What about allowing primitive types
> in newtypes?
>     λ:4> newtype Blah1 = Blah1 Int
>     λ:5> newtype Blah2 = Blah2 Int#
>     <interactive>:5:23: error:
>         • Expecting a lifted type, but ‘Int#’ is unlifted
>         • In the type ‘Int#’
>           In the definition of data constructor ‘Blah2’
>           In the newtype declaration for ‘Blah2’
> Ideally second definition should be OK, and kind of Blah2 should be #. Is
> this
> too hard to do?
> 2015-12-16 17:22 GMT-05:00 Richard Eisenberg <eir at>:
> >
> > On Dec 16, 2015, at 2:06 PM, Ömer Sinan Ağacan <omeragacan at>
> wrote:
> >>
> >> In any case, this is not that big deal. When I read the code I thought
> this
> >> should be a trivial change but apparently it's not.
> >
> > No, it's not. Your example (`f :: (Int#, b) -> b`) still has an unboxed
> thing in a boxed tuple. Boxed tuples simply can't (currently) hold unboxed
> things. And changing that is far from trivial. It's not the polymorphism
> that's the problem -- it's the unboxed thing in a boxed tuple.
> >
> > Richard
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the ghc-devs mailing list