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