<div dir="auto">Good point! Call it nominal then.</div><br><div class="gmail_quote"><div dir="ltr">On Mon, Oct 29, 2018, 5:24 PM Carter Schonwald <<a href="mailto:carter.schonwald@gmail.com">carter.schonwald@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">absolutely false, represeentational equality of the  type a in `Ptr a` does not mean the memory representation at the corresponding address is the same.<div>(it sometimes is true, but memory packing/alignment details in structs in C  for otherwise equivlanet structs should rule this out)</div><div><br></div><div>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</div><div>host and network byte order aren't the same (eg big vs little endian memory encodings)</div></div><br><div class="gmail_quote"><div dir="ltr">On Mon, Oct 29, 2018 at 12:28 PM David Feuer <<a href="mailto:david.feuer@gmail.com" target="_blank" rel="noreferrer">david.feuer@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">What? Of course you can dereference it. You dereference it, getting a<br>
value of type `Void`,<br>
and apply absurd to get whatever you want in the world. This, of<br>
course, is utter nonsense,<br>
unless *having* the Ptr Void means that something has already gone<br>
wrong. It's pretty<br>
hard for me to imagine a situation where this is actually what you<br>
want. A Ptr () isn't nonsense.<br>
It is not terrible to use Ptr () to represent an Addr, but I wonder if<br>
it sends the wrong message.<br>
By the way: there's another argument for having Addr in base for now.<br>
We would really<br>
*like* for Ptr's parameter to have a *representational* role, but we<br>
*don't* want to require<br>
unsafeCoerce to cast Ptrs. The solution to that in the current role system:<br>
<br>
    data Addr = Addr Addr#<br>
<br>
    newtype Ptr a = Ptr_ Addr<br>
    type role Ptr representational<br>
<br>
    pattern Ptr :: Addr# -> Ptr a<br>
    pattern Ptr addr# = Ptr_ (Addr addr#)<br>
<br>
    -- Allow users to reveal coercibility of pointer types locally<br>
    ptrCoercion :: Coercion (Ptr a) (Ptr b)<br>
    ptrCoercion = Coercion<br>
<br>
    castPtr :: Ptr a -> Ptr b<br>
    castPtr = coerceWith ptrCoercion -- (or the now-free unwrap-rewrap<br>
definition)<br>
<br>
<br>
So even if we don't *expose* Addr in base, we should almost certainly *define*<br>
it there.<br>
On Mon, Oct 29, 2018 at 12:11 PM Carter Schonwald<br>
<<a href="mailto:carter.schonwald@gmail.com" target="_blank" rel="noreferrer">carter.schonwald@gmail.com</a>> wrote:<br>
><br>
> 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!!<br>
><br>
><br>
><br>
> On Mon, Oct 29, 2018 at 10:10 AM David Feuer <<a href="mailto:david.feuer@gmail.com" target="_blank" rel="noreferrer">david.feuer@gmail.com</a>> wrote:<br>
>><br>
>> On Mon, Oct 29, 2018, 10:05 AM Sven Panne <<a href="mailto:svenpanne@gmail.com" target="_blank" rel="noreferrer">svenpanne@gmail.com</a>> wrote:<br>
>>><br>
>>> Am Mo., 29. Okt. 2018 um 14:27 Uhr schrieb Daniel Cartwright <<a href="mailto:chessai1996@gmail.com" target="_blank" rel="noreferrer">chessai1996@gmail.com</a>>:<br>
>>>><br>
>>>> 'Ptr Void' is not a pointer to a value of type 'Void'; there are no values of type 'Void': this type is nonsensical.<br>
>>><br>
>>><br>
>>> 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++.<br>
>><br>
>><br>
>> 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.<br>
>><br>
>>><br>
>>> You can't store or read "()", so the same holds as for Void (which didn't exist when the FFI was created IIRC).<br>
>><br>
>><br>
>> Sure you can. Storing () does nothing and reading it gives (). Our () is somewhat similar to C's void return type.<br>
>> _______________________________________________<br>
>> Libraries mailing list<br>
>> <a href="mailto:Libraries@haskell.org" target="_blank" rel="noreferrer">Libraries@haskell.org</a><br>
>> <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br>
</blockquote></div>
</blockquote></div>