Kinds of type synonym arguments

[Simon Peyton Jones]

newtype T = MkT Int#

Provided T :: # (i.e. unlifted), I don’t think this would be too hard.  That is, you can give a new name (via newtype) to an unlifted type like Int#, Float#, Double# etc.

Worth a wiki page and a ticket.

Simon

From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Edward Kmett
Sent: 21 December 2015 09:10
To: Ömer Sinan Ağacan <omeragacan at gmail.com>
Cc: ghc-devs <ghc-devs at haskell.org>
Subject: Re: Kinds of type synonym arguments

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.

-Edward

On Sun, Dec 20, 2015 at 2:14 PM, Ömer Sinan Ağacan <omeragacan at gmail.com<mailto:omeragacan at gmail.com>> wrote:
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 cis.upenn.edu<mailto:eir at cis.upenn.edu>>:
>
> On Dec 16, 2015, at 2:06 PM, Ömer Sinan Ağacan <omeragacan at gmail.com<mailto:omeragacan at gmail.com>> 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 haskell.org<mailto:ghc-devs at haskell.org>
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.haskell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc-devs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c4ba7cbf98af84227d01808d309e6931f%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=nmxCKI9q3o%2b1pw%2f8phLXRWHv3QZ1xUpyAbN5CmyUwxQ%3d>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151221/b0b085c5/attachment-0001.html>