Mark ForeignPtr as representational
Needs ReviewPublic

Authored by mpickering on Fri, Jul 6, 8:41 AM.

Details

Reviewers
idontgetoutmuch
hvr
bgamari
Trac Issues
#9163
Summary

As the wiki page explains, Ptr needs to have a representation role. The
same logic follows for ForeignPtr.

Without a representational role it is inferred as phantom which means
you can coerce ForeignPtr Int to ForeignPtr Bool with unexpected
consequences.

This exhibits itself in the real world in Data.Vector.Storable.Vector.

mpickering created this revision.Fri, Jul 6, 8:41 AM

I'm confused. Ptr is definitely not representationally roled in its argument, as explained here.

What's the point of having any type argument on Ptr if it's phantom?

I'm not sure if Phabricator is a good place to have this discussion—I'd recommend bringing this up on Trac #9163, where this was originally decided.

What's the point of having any type argument on Ptr if it's phantom?

Well, by this argument what would be the point of having *any* phantom type arguments?

It seems to me that there is still a "trust me" component to coerce when phantoms are involved. You won't cause a segfault (at least from interpretation of the Haskell object), but it's still somewhat up to the user to make sure that the value is still semantically reasonable.

@bgamari - I'd rather get a segfault than this

*Numeric.Sundials.CVode.ODE> (coerce ((V.fromList [1,2]) :: Vector CInt)) :: Vector Int
[8589934593,4426664329]

@bgamari - I'd rather get a segfault than this

*Numeric.Sundials.CVode.ODE> (coerce ((V.fromList [1,2]) :: Vector CInt)) :: Vector Int
[8589934593,4426664329]

That is a fair point; I suppose this being phantom can have some rather subtle consequences.

bgamari updated the Trac tickets for this revision.Thu, Jul 12, 1:52 PM