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

Repeating it’s a lie isn’t an argument. Writing code and comparing it is a way to make a case. I even put some up on phabticator. Then decided it’s actually not a useful piece of code. I’ve spoke with a number of folks privately and I’m arriculating the lack of suport and clear case. I’m open to being wrong and that this proposal is great. But changing a type signature isn’t show casing what code is improved. It’s just a proof that the change can be made. I need evidence. As does everyone :) On Tue, Oct 30, 2018 at 12:25 PM David Feuer wrote:

Thankfully, Carter, you're not the sole arbiter of whether a library proposal is dead. The discussion can surely continue without you.

On Tue, Oct 30, 2018, 12:22 PM Carter Schonwald < carter.schonwald@gmail.com> wrote:

...

Anyways. This proposal is dead.

Changing this internal stuff from Ptr to Addr doesn’t make an argument that the code is better for it. That has not be made.

Saying ptr a is a lie is about as informative as saying virtual memory is a lie. Or the cpu caches are a lie.

Evidence works. Saying something is a lie doesn’t.

On Tue, Oct 30, 2018 at 12:11 PM Carter Schonwald < carter.schonwald@gmail.com> wrote:

...

There’s no class constraint here, so I would instead assume I need to read the paper / docs and source code for how heap objects are encoded here. Changing the type to Addr vs Ptr a or Ptr void is a red herring / irrelevant

On Tue, Oct 30, 2018 at 12:09 PM Carter Schonwald < carter.schonwald@gmail.com> wrote:

...

This example seems more a discussion about how the ghc-compact lib could benefit from better docs.

On Tue, Oct 30, 2018 at 11:48 AM Andrew Martin < andrew.thaddeus@gmail.com> wrote:

...

Look at the definition of SerializedCompact (in ghc-compact):

data SerializedCompact a = SerializedCompact { serializedCompactBlockList :: [(Ptr a, Word)] , serializedCompactRoot :: Ptr a }

The type variables on those Ptrs are a lie. The SerializedCompact needs that phantom type variable to keep track of what type of object in a compact region is represented by these blocks. But, the types of its two fields are extremely misleading. When I first saw this type, I was led to believe that I could call `peek` on the `serializedCompactRoot` field and get a value of type `a`. You cannot actually do that since it isn't actually a pointer to a value of that type. More correct would be:

data SerializedCompact a = SerializedCompact { serializedCompactBlockList :: [(Addr, Word)] , serializedCompactRoot :: Addr }

This better documents what's actually going on here. We don't have a bunch of pointers to `a` values in a list. We value memory addresses that refer to arbitrary fragments of an object on the heap.

On Tue, Oct 30, 2018 at 11:32 AM Carter Schonwald < carter.schonwald@gmail.com> wrote:

...

Daniel : at this point you’re not show casing examples of why Address leads to better code than Pointer a

A good library proposal makes code *better* in an unambiguous way. As I mentioned yesterday , that’s been lacking here. Or any improvements are ones sven , myself and others don’t see. :)

On Tue, Oct 30, 2018 at 10:41 AM Sven Panne wrote:

> Am Di., 30. Okt. 2018 um 15:18 Uhr schrieb Daniel Cartwright < > chessai1996@gmail.com>: > >> > hPutBuf doesn't care about what stuff has been written into the >> given buffer, it just cares about its start and its size. >> Seems like a good use for Addr? >> > > Nope, not at all: Using a free type variable like "a" in such a > situation is *the* common idiom to specify that the function doesn't care > about the type, just like "length" doesn't care about the type of the > elements. If you don't like that idiom, fine, but it has been officially > enshrined in the standard and people are using it for decades (well, > almost) without any problems, at least I haven't heard of them. > > What would using Addr buy us? Addr is non-standard, and you would > have to use some cast from a Ptr somehow (the world outside GHC's innards > is using Ptr, not Addr). This would buy you exactly zero safety or clarity, > and it would only introduce API friction. > > >> > If you have a pointer pointing to something and shift that >> pointer by some bytes, you are probably pointing to something completely >> different, so of course "b" and "a" have nothing to do with each other. So >> peekByteOff intentionally ignores "b". >> This also seems like a good use for Addr? >> > Nope again, see above. > > I still fail to see what problem this whole proposal is actually > trying to solve... > _______________________________________________

...

Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

-- -Andrew Thaddeus Martin

_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries