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

[David Feuer]

Good point! Call it nominal then.

On Mon, Oct 29, 2018, 5:24 PM Carter Schonwald <carter.schonwald at gmail.com>
wrote:

> 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/746ec607/attachment-0001.html>