Proposal: Move primitive-Data.Primitive.Addr API into base

[Carter Schonwald]

absolutely false, represeentational equality of the  type a in `Ptr a` does
not mean the memory representation at the corresponding address is the same.
(it sometimes is true, but memory packing/alignment details in structs in
C  for otherwise equivlanet structs should rule this out)

aka, `a` being representationally equal to `b` via haskell newtypes does
not mean the memory representation at `Ptr a`, and `Ptr b` are the same. a
trivial example is when
host and network byte order aren't the same (eg big vs little endian memory
encodings)

On Mon, Oct 29, 2018 at 12:28 PM David Feuer <david.feuer at gmail.com> wrote:

> What? Of course you can dereference it. You dereference it, getting a
> value of type `Void`,
> and apply absurd to get whatever you want in the world. This, of
> course, is utter nonsense,
> unless *having* the Ptr Void means that something has already gone
> wrong. It's pretty
> hard for me to imagine a situation where this is actually what you
> want. A Ptr () isn't nonsense.
> It is not terrible to use Ptr () to represent an Addr, but I wonder if
> it sends the wrong message.
> By the way: there's another argument for having Addr in base for now.
> We would really
> *like* for Ptr's parameter to have a *representational* role, but we
> *don't* want to require
> unsafeCoerce to cast Ptrs. The solution to that in the current role system:
>
>     data Addr = Addr Addr#
>
>     newtype Ptr a = Ptr_ Addr
>     type role Ptr representational
>
>     pattern Ptr :: Addr# -> Ptr a
>     pattern Ptr addr# = Ptr_ (Addr addr#)
>
>     -- Allow users to reveal coercibility of pointer types locally
>     ptrCoercion :: Coercion (Ptr a) (Ptr b)
>     ptrCoercion = Coercion
>
>     castPtr :: Ptr a -> Ptr b
>     castPtr = coerceWith ptrCoercion -- (or the now-free unwrap-rewrap
> definition)
>
>
> So even if we don't *expose* Addr in base, we should almost certainly
> *define*
> it there.
> On Mon, Oct 29, 2018 at 12:11 PM Carter Schonwald
> <carter.schonwald at gmail.com> wrote:
> >
> > The point , hahah, of a Ptr void is that you can’t dereference it.  But
> you certainly can cast it and do address arithmetic on it!!
> >
> >
> >
> > On Mon, Oct 29, 2018 at 10:10 AM David Feuer <david.feuer at gmail.com>
> wrote:
> >>
> >> On Mon, Oct 29, 2018, 10:05 AM Sven Panne <svenpanne at gmail.com> wrote:
> >>>
> >>> Am Mo., 29. Okt. 2018 um 14:27 Uhr schrieb Daniel Cartwright <
> chessai1996 at gmail.com>:
> >>>>
> >>>> 'Ptr Void' is not a pointer to a value of type 'Void'; there are no
> values of type 'Void': this type is nonsensical.
> >>>
> >>>
> >>> That's the whole point, and it actually makes sense: If you see "Ptr
> Void", you can't do much with it, apart from passing it around or using
> castPtr on it. This is exactly what should be achieved by using "Ptr Void"
> in an API. This is basically the same as "void *" in C/C++.
> >>
> >>
> >> No, it does not make sense. The approximate equivalent of C's void* is
> Ptr Any. Ptr Void promises to give you anything you want on dereference,
> which is nonsense.
> >>
> >>>
> >>> You can't store or read "()", so the same holds as for Void (which
> didn't exist when the FFI was created IIRC).
> >>
> >>
> >> Sure you can. Storing () does nothing and reading it gives (). Our ()
> is somewhat similar to C's void return type.
> >> _______________________________________________
> >> Libraries mailing list
> >> Libraries at haskell.org
> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20181029/7166a998/attachment.html>