Proposal: give Ptr a nominal role

[Bertram Felgenhauer]

David Feuer wrote:
> Indeed. I think the point is that Ptr should be thought of as tied to
> Storable. If you want to use an Addr# for something else, then you
> shouldn't be using Ptr!

Thanks for that... This indeed seems to be the heart of this discussion,
and the Addr thread as well.

Currently, Ptr a serves a double role, with at least three facets:

1. Storable a => Ptr a, where the Storable instance describes the object
  being pointed to. This has an internal and a user-facing facet:

  * user-facing: peekElemOff, pokeElemOff, peek, poke
    for accessing the stored objects

  * internal: peekByteOff, pokeByteOff
    these can be used to access subobjects of a larger objects, for
    example when implementing a Storable instance for a C struct

2. Ptr a, a type-tagged address with no further semantics; also used
  as plain addresses (Ptr () or fully polymorphic Ptr a).

  * the internal Storable API can be re-used for such type-tagged
    pointers.

I for one am happy with maintaining this double role, because it's
well established, and econmical (no duplication of APIs just for
dealing with plain addresses), and I don't see how code dealing with
pointers would automatically become more correct by introducing an
extra type for the second role. (This is tricky; code becomes more
correct only if more actual errors become type errors without
introducing many false positives. This lack of false positives is
important; if the code becomes littered with explicit conversions as
a result of introducing an extra type, then the signaling value of
such conversions is lost.) But obviously there's room for different
opinions on this.

As for the question whether the argument of Ptr should be nominal or
phantom, again I don't see a big difference; coercions have to be
explicit either way, and all code dealing with Ptr is unsafe to begin
with.

Cheers,

Bertram