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

Tue Oct 30 00:39:19 UTC 2018

You mean Nothing and (Just 0) have actually different sizes? That's so
weird for a former C++ programmer.

2018년 10월 30일 (화) 09:35, Carter Schonwald <carter.schonwald at gmail.com>님이 작성:

> @danny... storable is only for fixed size pinned memory values
>
> On Mon, Oct 29, 2018 at 8:31 PM Dannyu NDos <ndospark320 at gmail.com> wrote:
>
>> It is Storable that makes Ptr operate as typed pointers. I also think Ptr
>> on its own doesn't have that much about its argument type, so I'm +1 on the
>> proposal.
>>
>> Btw, shouldn't every type be storable? In current Haskell, Maybes or
>> (->)s aren't Storable, yet in C++, arrays of std::optionals or
>> std::functions are well-defined.
>>
>> As an exception, for Void, I agree that they must remain not Storable
>> since it has no values.
>>
>> 2018년 10월 30일 (화) 08:31, Carter Schonwald <carter.schonwald at gmail.com>님이
>> 작성:
>>
>>> the parametricity isn't for when you know things, its for saying "these
>>> are possibly different or possibly the same, dont let me mix them up
>>> though, cause I dont know yet"
>>>
>>>
>>> On Mon, Oct 29, 2018 at 7:03 PM Daniel Cartwright <chessai1996 at gmail.com>
>>> wrote:
>>>
>>>> I'm not sure that argument applies at all, when talking about
>>>> _incorrect_ usages of Ptr. Sure, Addr probably shouldn't be used when there
>>>> is meaningful type information/value to recover, but neither should Ptr be
>>>> used when there is none.
>>>>
>>>> The argument being made is not to make 'better', per se, and there
>>>> definitely won't be a 'mathematical statement' about this, but it certainly
>>>> may be made clearer - in my opinion, the usages of 'Ptr' that i've already
>>>> brought up are inherently unclear because of the bogus phantom type
>>>> associated with 'Ptr'. The illustration of this begs no code that doesn't
>>>> already exist in corelibs.
>>>>
>>>>
>>>> On Mon, Oct 29, 2018 at 6:19 PM Carter Schonwald <
>>>> carter.schonwald at gmail.com> wrote:
>>>>
>>>>> to zoom out: what code is improved? what code is made better/clearer?
>>>>> No one has articulated this clearly.
>>>>>
>>>>> The one example of Addr being used in Vector.Storable.Mutable is not
>>>>> an argument in favor of using Addr. Its an argument against it existing.
>>>>>
>>>>> i'm looking for evidence, in the form of code i can look at then say
>>>>> "yes, this is better code" when comparing the two. Or a mathematical
>>>>> statement of "what is made better"
>>>>>
>>>>> @David Feuer <david.feuer at gmail.com> , @Daniel , do you have one?
>>>>>
>>>>> when i'm writing complicated code, MORE polymorphism helps me usually.
>>>>>
>>>>> I can write some code like the following and even though I'm using it
>>>>> with Int at argument,
>>>>> I *Know* that i'm not mixing up arguments/values that i write as
>>>>> different types. I cannot do this with Address!
>>>>> (the type / function below can be found at
>>>>> https://github.com/wellposed/numerical/blob/3a0bbf50bc6ce0b710aee755f5a4bfce08af4201/src/Numerical/Array/Layout/Builder.hs#L294
>>>>> )
>>>>>
>>>>> {-# SPECIALIZE INLINE computeStarts :: [(Int,Int)]->Int->Int
>>>>> ->[(Int,Int)] #-}
>>>>> computeStarts:: (Enum a, Ord a, Num b )=>[(a,b)]-> a -> a -> [(a,b)]
>>>>>
>>>>> parametricity (even when constrained by type classes) is a powerful
>>>>> and foundational tool for good programming in haskell and similar languages
>>>>>
>>>>> there has been nothing stated here that successfully articulates a
>>>>> good reason to forgo/discourage parametricity as an engineering tool. for
>>>>> thats what Addr is.
>>>>> A datatype thats never safe in isolation, and discourages using
>>>>> parametricity to write correct software.
>>>>>
>>>>> a very strong case is needed to forgo parametricity.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Mon, Oct 29, 2018 at 5:33 PM David Feuer <david.feuer at gmail.com>
>>>>> wrote:
>>>>>
>>>>>> 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
>>>>>>>>
>>>>>>> _______________________________________________
>>>>> Libraries mailing list
>>>>> Libraries at haskell.org
>>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>>>>
>>>> _______________________________________________
>>> 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/20181030/11bbcdb2/attachment.html>