Ptr type

[Richard Eisenberg]

It seemed clear to me that Ptr *should* be representational, thinking that we don't want to coerce a `Ptr Int` to a `Ptr Bool`. I don't see any reason why this couldn't be changed.

Why is Ptr a `data` not a `newtype`? If it were a newtype, we could keep the role annotation and use `coerce` internally, according to the updated Coercible solver.

However, it is crucial that FunPtr have a representational argument, as normaliseFfiType' depends on this fact. There is a brief comment in TcForeign, but clearly more comments are necessary. Will do shortly. If we want to change FunPtr's role, normaliseFfiType' would have to be updated, too, but it shouldn't be hard.

More comments in the code later today.

Richard

On Jun 3, 2014, at 7:13 AM, Simon Peyton Jones <simonpj at microsoft.com> wrote:

> Richard
> 
> In GHC.Ptr we see
> 
> type role Ptr representational
> data Ptr a = Ptr Addr# deriving (Eq, Ord)
> with no comments.  Why is Ptr representational?
> 
> In the same module we have castPtr, which unpacks and repacks a Ptr.  If Ptr was phantom, we could use coerce.  And that in turn would actually make a lot of code more efficient – there are lots of calls to castPtr.
> 
> Simon
> 
>  
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140603/f6ea6e3d/attachment.html>