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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
87 messages Options
12345
Reply | Threaded
Open this post in threaded view
|

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

chessai .
Motivation: There are a lot of places in base where 'Ptr a' is used in place of 'Addr', because in base there is no 'Addr', only 'Addr#'. The problem lies in the fact that many of these uses of 'Ptr a' are lying; the 'a' value is meaningless. Authors of functions therein have used things like 'Ptr ()', 'Ptr Word8', 'Ptr a', but these types do not mean what they say they mean - they're just Addr. There are probably other motivations for this that I can't think of off the top of my head right now.

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

David Feuer
I concur. Addr is the "natural" wrapper for Addr#, and I believe all such natural wrappers belong in base.

On Thu, Oct 25, 2018, 11:25 AM Daniel Cartwright <[hidden email]> wrote:
Motivation: There are a lot of places in base where 'Ptr a' is used in place of 'Addr', because in base there is no 'Addr', only 'Addr#'. The problem lies in the fact that many of these uses of 'Ptr a' are lying; the 'a' value is meaningless. Authors of functions therein have used things like 'Ptr ()', 'Ptr Word8', 'Ptr a', but these types do not mean what they say they mean - they're just Addr. There are probably other motivations for this that I can't think of off the top of my head right now.
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

Andrew Martin
In reply to this post by chessai .
I like the idea of moving the type Addr into base. But we cannot move the entire module since it has functions that talk about PrimMonad, and we definitely don't want to move that into base.

On Thu, Oct 25, 2018 at 11:25 AM Daniel Cartwright <[hidden email]> wrote:
Motivation: There are a lot of places in base where 'Ptr a' is used in place of 'Addr', because in base there is no 'Addr', only 'Addr#'. The problem lies in the fact that many of these uses of 'Ptr a' are lying; the 'a' value is meaningless. Authors of functions therein have used things like 'Ptr ()', 'Ptr Word8', 'Ptr a', but these types do not mean what they say they mean - they're just Addr. There are probably other motivations for this that I can't think of off the top of my head right now.
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries


--
-Andrew Thaddeus Martin

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

Carter Schonwald
Indeed.  The monad transformer instances for primmonad need to live in primmonad OR transformers to avoid orphans. 

Either way, unless transformers moves into base (unlikely), no way anything using prim monad will. 

On Thu, Oct 25, 2018 at 3:34 PM Andrew Martin <[hidden email]> wrote:
I like the idea of moving the type Addr into base. But we cannot move the entire module since it has functions that talk about PrimMonad, and we definitely don't want to move that into base.

On Thu, Oct 25, 2018 at 11:25 AM Daniel Cartwright <[hidden email]> wrote:
Motivation: There are a lot of places in base where 'Ptr a' is used in place of 'Addr', because in base there is no 'Addr', only 'Addr#'. The problem lies in the fact that many of these uses of 'Ptr a' are lying; the 'a' value is meaningless. Authors of functions therein have used things like 'Ptr ()', 'Ptr Word8', 'Ptr a', but these types do not mean what they say they mean - they're just Addr. There are probably other motivations for this that I can't think of off the top of my head right now.
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries


--
-Andrew Thaddeus Martin
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

David Feuer
We shouldn't really need to move anything into base except Addr and its base instances.

On Oct 25, 2018 5:59 PM, "Carter Schonwald" <[hidden email]> wrote:
Indeed.  The monad transformer instances for primmonad need to live in primmonad OR transformers to avoid orphans. 

Either way, unless transformers moves into base (unlikely), no way anything using prim monad will. 

On Thu, Oct 25, 2018 at 3:34 PM Andrew Martin <[hidden email]> wrote:
I like the idea of moving the type Addr into base. But we cannot move the entire module since it has functions that talk about PrimMonad, and we definitely don't want to move that into base.

On Thu, Oct 25, 2018 at 11:25 AM Daniel Cartwright <[hidden email]> wrote:
Motivation: There are a lot of places in base where 'Ptr a' is used in place of 'Addr', because in base there is no 'Addr', only 'Addr#'. The problem lies in the fact that many of these uses of 'Ptr a' are lying; the 'a' value is meaningless. Authors of functions therein have used things like 'Ptr ()', 'Ptr Word8', 'Ptr a', but these types do not mean what they say they mean - they're just Addr. There are probably other motivations for this that I can't think of off the top of my head right now.
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries


--
-Andrew Thaddeus Martin
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries


_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

Carter Schonwald
hrmm, what are the pieces of base that are using Ptr when they really should be using Addr? This would help me understand what would be made better in base :) 

On Thu, Oct 25, 2018 at 6:19 PM David Feuer <[hidden email]> wrote:
We shouldn't really need to move anything into base except Addr and its base instances.

On Oct 25, 2018 5:59 PM, "Carter Schonwald" <[hidden email]> wrote:
Indeed.  The monad transformer instances for primmonad need to live in primmonad OR transformers to avoid orphans. 

Either way, unless transformers moves into base (unlikely), no way anything using prim monad will. 

On Thu, Oct 25, 2018 at 3:34 PM Andrew Martin <[hidden email]> wrote:
I like the idea of moving the type Addr into base. But we cannot move the entire module since it has functions that talk about PrimMonad, and we definitely don't want to move that into base.

On Thu, Oct 25, 2018 at 11:25 AM Daniel Cartwright <[hidden email]> wrote:
Motivation: There are a lot of places in base where 'Ptr a' is used in place of 'Addr', because in base there is no 'Addr', only 'Addr#'. The problem lies in the fact that many of these uses of 'Ptr a' are lying; the 'a' value is meaningless. Authors of functions therein have used things like 'Ptr ()', 'Ptr Word8', 'Ptr a', but these types do not mean what they say they mean - they're just Addr. There are probably other motivations for this that I can't think of off the top of my head right now.
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries


--
-Andrew Thaddeus Martin
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries


_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

chessai .
yes, only the type and its instances should be moved as far as i'm aware.

Also, it's more than just base.

in GHC.Stats, the foreign import "getRTSStats" has `Ptr () -> IO ()`, this Ptr () is also a lie

These are just off the top of my head, there are more


On Thu, Oct 25, 2018 at 6:46 PM Carter Schonwald <[hidden email]> wrote:
hrmm, what are the pieces of base that are using Ptr when they really should be using Addr? This would help me understand what would be made better in base :) 

On Thu, Oct 25, 2018 at 6:19 PM David Feuer <[hidden email]> wrote:
We shouldn't really need to move anything into base except Addr and its base instances.

On Oct 25, 2018 5:59 PM, "Carter Schonwald" <[hidden email]> wrote:
Indeed.  The monad transformer instances for primmonad need to live in primmonad OR transformers to avoid orphans. 

Either way, unless transformers moves into base (unlikely), no way anything using prim monad will. 

On Thu, Oct 25, 2018 at 3:34 PM Andrew Martin <[hidden email]> wrote:
I like the idea of moving the type Addr into base. But we cannot move the entire module since it has functions that talk about PrimMonad, and we definitely don't want to move that into base.

On Thu, Oct 25, 2018 at 11:25 AM Daniel Cartwright <[hidden email]> wrote:
Motivation: There are a lot of places in base where 'Ptr a' is used in place of 'Addr', because in base there is no 'Addr', only 'Addr#'. The problem lies in the fact that many of these uses of 'Ptr a' are lying; the 'a' value is meaningless. Authors of functions therein have used things like 'Ptr ()', 'Ptr Word8', 'Ptr a', but these types do not mean what they say they mean - they're just Addr. There are probably other motivations for this that I can't think of off the top of my head right now.
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries


--
-Andrew Thaddeus Martin
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

chessai .
In reply to this post by chessai .
Oh, another motivation might be: users wish to use `Addr` without incurring a dependency on `primitive`.

On Thu, Oct 25, 2018 at 11:24 AM Daniel Cartwright <[hidden email]> wrote:
Motivation: There are a lot of places in base where 'Ptr a' is used in place of 'Addr', because in base there is no 'Addr', only 'Addr#'. The problem lies in the fact that many of these uses of 'Ptr a' are lying; the 'a' value is meaningless. Authors of functions therein have used things like 'Ptr ()', 'Ptr Word8', 'Ptr a', but these types do not mean what they say they mean - they're just Addr. There are probably other motivations for this that I can't think of off the top of my head right now.

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

chessai .
In reply to this post by chessai .
Now, one could argue that `Ptr ()` isn't a lie, it sort of reads like C's void pointer. But surely something like `Ptr Word8` is a lie, when it is not actually a Ptr to Word8 values.

On Thu, Oct 25, 2018 at 8:11 PM Daniel Cartwright <[hidden email]> wrote:
yes, only the type and its instances should be moved as far as i'm aware.

Also, it's more than just base.

in GHC.Stats, the foreign import "getRTSStats" has `Ptr () -> IO ()`, this Ptr () is also a lie

These are just off the top of my head, there are more


On Thu, Oct 25, 2018 at 6:46 PM Carter Schonwald <[hidden email]> wrote:
hrmm, what are the pieces of base that are using Ptr when they really should be using Addr? This would help me understand what would be made better in base :) 

On Thu, Oct 25, 2018 at 6:19 PM David Feuer <[hidden email]> wrote:
We shouldn't really need to move anything into base except Addr and its base instances.

On Oct 25, 2018 5:59 PM, "Carter Schonwald" <[hidden email]> wrote:
Indeed.  The monad transformer instances for primmonad need to live in primmonad OR transformers to avoid orphans. 

Either way, unless transformers moves into base (unlikely), no way anything using prim monad will. 

On Thu, Oct 25, 2018 at 3:34 PM Andrew Martin <[hidden email]> wrote:
I like the idea of moving the type Addr into base. But we cannot move the entire module since it has functions that talk about PrimMonad, and we definitely don't want to move that into base.

On Thu, Oct 25, 2018 at 11:25 AM Daniel Cartwright <[hidden email]> wrote:
Motivation: There are a lot of places in base where 'Ptr a' is used in place of 'Addr', because in base there is no 'Addr', only 'Addr#'. The problem lies in the fact that many of these uses of 'Ptr a' are lying; the 'a' value is meaningless. Authors of functions therein have used things like 'Ptr ()', 'Ptr Word8', 'Ptr a', but these types do not mean what they say they mean - they're just Addr. There are probably other motivations for this that I can't think of off the top of my head right now.
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries


--
-Andrew Thaddeus Martin
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

Carter Schonwald
... when is a valid pointer not going to point at byte addressable memory on memory architectures ghc can support or target? 

On Thu, Oct 25, 2018 at 8:27 PM Daniel Cartwright <[hidden email]> wrote:
Now, one could argue that `Ptr ()` isn't a lie, it sort of reads like C's void pointer. But surely something like `Ptr Word8` is a lie, when it is not actually a Ptr to Word8 values.

On Thu, Oct 25, 2018 at 8:11 PM Daniel Cartwright <[hidden email]> wrote:
yes, only the type and its instances should be moved as far as i'm aware.

Also, it's more than just base.

in GHC.Stats, the foreign import "getRTSStats" has `Ptr () -> IO ()`, this Ptr () is also a lie

These are just off the top of my head, there are more


On Thu, Oct 25, 2018 at 6:46 PM Carter Schonwald <[hidden email]> wrote:
hrmm, what are the pieces of base that are using Ptr when they really should be using Addr? This would help me understand what would be made better in base :) 

On Thu, Oct 25, 2018 at 6:19 PM David Feuer <[hidden email]> wrote:
We shouldn't really need to move anything into base except Addr and its base instances.

On Oct 25, 2018 5:59 PM, "Carter Schonwald" <[hidden email]> wrote:
Indeed.  The monad transformer instances for primmonad need to live in primmonad OR transformers to avoid orphans. 

Either way, unless transformers moves into base (unlikely), no way anything using prim monad will. 

On Thu, Oct 25, 2018 at 3:34 PM Andrew Martin <[hidden email]> wrote:
I like the idea of moving the type Addr into base. But we cannot move the entire module since it has functions that talk about PrimMonad, and we definitely don't want to move that into base.

On Thu, Oct 25, 2018 at 11:25 AM Daniel Cartwright <[hidden email]> wrote:
Motivation: There are a lot of places in base where 'Ptr a' is used in place of 'Addr', because in base there is no 'Addr', only 'Addr#'. The problem lies in the fact that many of these uses of 'Ptr a' are lying; the 'a' value is meaningless. Authors of functions therein have used things like 'Ptr ()', 'Ptr Word8', 'Ptr a', but these types do not mean what they say they mean - they're just Addr. There are probably other motivations for this that I can't think of off the top of my head right now.
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries


--
-Andrew Thaddeus Martin
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

Carter Schonwald
Pretending we’re talking about this with storable as our example semantics : 

Ptr Void 
Corresponds to a memory address you don’t want to read or write to.  

Ptr () corresponds to a memory location that’s pretty boring to read / write to 


It’s definitely also true that for nontrivial c data structures , storable isn’t the right model for how to interact with the associated pointers.  

On Thu, Oct 25, 2018 at 11:22 PM Carter Schonwald <[hidden email]> wrote:
... when is a valid pointer not going to point at byte addressable memory on memory architectures ghc can support or target? 

On Thu, Oct 25, 2018 at 8:27 PM Daniel Cartwright <[hidden email]> wrote:
Now, one could argue that `Ptr ()` isn't a lie, it sort of reads like C's void pointer. But surely something like `Ptr Word8` is a lie, when it is not actually a Ptr to Word8 values.

On Thu, Oct 25, 2018 at 8:11 PM Daniel Cartwright <[hidden email]> wrote:
yes, only the type and its instances should be moved as far as i'm aware.

Also, it's more than just base.

in GHC.Stats, the foreign import "getRTSStats" has `Ptr () -> IO ()`, this Ptr () is also a lie

These are just off the top of my head, there are more


On Thu, Oct 25, 2018 at 6:46 PM Carter Schonwald <[hidden email]> wrote:
hrmm, what are the pieces of base that are using Ptr when they really should be using Addr? This would help me understand what would be made better in base :) 

On Thu, Oct 25, 2018 at 6:19 PM David Feuer <[hidden email]> wrote:
We shouldn't really need to move anything into base except Addr and its base instances.

On Oct 25, 2018 5:59 PM, "Carter Schonwald" <[hidden email]> wrote:
Indeed.  The monad transformer instances for primmonad need to live in primmonad OR transformers to avoid orphans. 

Either way, unless transformers moves into base (unlikely), no way anything using prim monad will. 

On Thu, Oct 25, 2018 at 3:34 PM Andrew Martin <[hidden email]> wrote:
I like the idea of moving the type Addr into base. But we cannot move the entire module since it has functions that talk about PrimMonad, and we definitely don't want to move that into base.

On Thu, Oct 25, 2018 at 11:25 AM Daniel Cartwright <[hidden email]> wrote:
Motivation: There are a lot of places in base where 'Ptr a' is used in place of 'Addr', because in base there is no 'Addr', only 'Addr#'. The problem lies in the fact that many of these uses of 'Ptr a' are lying; the 'a' value is meaningless. Authors of functions therein have used things like 'Ptr ()', 'Ptr Word8', 'Ptr a', but these types do not mean what they say they mean - they're just Addr. There are probably other motivations for this that I can't think of off the top of my head right now.
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries


--
-Andrew Thaddeus Martin
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

David Feuer
In reply to this post by Carter Schonwald
Ptr Word8 is not (just) a pointer to byte-addressable memory. It's specifically a pointer to something representing an 8-bit unsigned integer. If you use a Ptr Word8 for the address of a floating point value, then you are *wrong* (or doing something very weird, anyway). To quote the documentation,

A value of type Ptr a represents a pointer to an object, or an array of objects, which may be marshalled to or from Haskell values of type a.

On Thu, Oct 25, 2018, 11:23 PM Carter Schonwald <[hidden email]> wrote:
... when is a valid pointer not going to point at byte addressable memory on memory architectures ghc can support or target? 

On Thu, Oct 25, 2018 at 8:27 PM Daniel Cartwright <[hidden email]> wrote:
Now, one could argue that `Ptr ()` isn't a lie, it sort of reads like C's void pointer. But surely something like `Ptr Word8` is a lie, when it is not actually a Ptr to Word8 values.

On Thu, Oct 25, 2018 at 8:11 PM Daniel Cartwright <[hidden email]> wrote:
yes, only the type and its instances should be moved as far as i'm aware.

Also, it's more than just base.

in GHC.Stats, the foreign import "getRTSStats" has `Ptr () -> IO ()`, this Ptr () is also a lie

These are just off the top of my head, there are more


On Thu, Oct 25, 2018 at 6:46 PM Carter Schonwald <[hidden email]> wrote:
hrmm, what are the pieces of base that are using Ptr when they really should be using Addr? This would help me understand what would be made better in base :) 

On Thu, Oct 25, 2018 at 6:19 PM David Feuer <[hidden email]> wrote:
We shouldn't really need to move anything into base except Addr and its base instances.

On Oct 25, 2018 5:59 PM, "Carter Schonwald" <[hidden email]> wrote:
Indeed.  The monad transformer instances for primmonad need to live in primmonad OR transformers to avoid orphans. 

Either way, unless transformers moves into base (unlikely), no way anything using prim monad will. 

On Thu, Oct 25, 2018 at 3:34 PM Andrew Martin <[hidden email]> wrote:
I like the idea of moving the type Addr into base. But we cannot move the entire module since it has functions that talk about PrimMonad, and we definitely don't want to move that into base.

On Thu, Oct 25, 2018 at 11:25 AM Daniel Cartwright <[hidden email]> wrote:
Motivation: There are a lot of places in base where 'Ptr a' is used in place of 'Addr', because in base there is no 'Addr', only 'Addr#'. The problem lies in the fact that many of these uses of 'Ptr a' are lying; the 'a' value is meaningless. Authors of functions therein have used things like 'Ptr ()', 'Ptr Word8', 'Ptr a', but these types do not mean what they say they mean - they're just Addr. There are probably other motivations for this that I can't think of off the top of my head right now.
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries


--
-Andrew Thaddeus Martin
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

David Feuer
In reply to this post by Carter Schonwald
On Thu, Oct 25, 2018, 11:28 PM Carter Schonwald <[hidden email]> wrote:
Pretending we’re talking about this with storable as our example semantics : 

Ptr Void 
Corresponds to a memory address you don’t want to read or write to.

This is not so easy to think about (there's not much utility in such a type). Perhaps Ptr Void is a reasonable type for pointers known to be null or outside the address space, but I'm not sure.


Ptr () corresponds to a memory location that’s pretty boring to read / write to

Yes! In other words, it's *not* what people should be using for a pointer to an arbitrary non-Haskell address. That's precisely what Addr is for.


On Thu, Oct 25, 2018 at 11:22 PM Carter Schonwald <[hidden email]> wrote:
... when is a valid pointer not going to point at byte addressable memory on memory architectures ghc can support or target? 

On Thu, Oct 25, 2018 at 8:27 PM Daniel Cartwright <[hidden email]> wrote:
Now, one could argue that `Ptr ()` isn't a lie, it sort of reads like C's void pointer. But surely something like `Ptr Word8` is a lie, when it is not actually a Ptr to Word8 values.

On Thu, Oct 25, 2018 at 8:11 PM Daniel Cartwright <[hidden email]> wrote:
yes, only the type and its instances should be moved as far as i'm aware.

Also, it's more than just base.

in GHC.Stats, the foreign import "getRTSStats" has `Ptr () -> IO ()`, this Ptr () is also a lie

These are just off the top of my head, there are more


On Thu, Oct 25, 2018 at 6:46 PM Carter Schonwald <[hidden email]> wrote:
hrmm, what are the pieces of base that are using Ptr when they really should be using Addr? This would help me understand what would be made better in base :) 

On Thu, Oct 25, 2018 at 6:19 PM David Feuer <[hidden email]> wrote:
We shouldn't really need to move anything into base except Addr and its base instances.

On Oct 25, 2018 5:59 PM, "Carter Schonwald" <[hidden email]> wrote:
Indeed.  The monad transformer instances for primmonad need to live in primmonad OR transformers to avoid orphans. 

Either way, unless transformers moves into base (unlikely), no way anything using prim monad will. 

On Thu, Oct 25, 2018 at 3:34 PM Andrew Martin <[hidden email]> wrote:
I like the idea of moving the type Addr into base. But we cannot move the entire module since it has functions that talk about PrimMonad, and we definitely don't want to move that into base.

On Thu, Oct 25, 2018 at 11:25 AM Daniel Cartwright <[hidden email]> wrote:
Motivation: There are a lot of places in base where 'Ptr a' is used in place of 'Addr', because in base there is no 'Addr', only 'Addr#'. The problem lies in the fact that many of these uses of 'Ptr a' are lying; the 'a' value is meaningless. Authors of functions therein have used things like 'Ptr ()', 'Ptr Word8', 'Ptr a', but these types do not mean what they say they mean - they're just Addr. There are probably other motivations for this that I can't think of off the top of my head right now.
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries


--
-Andrew Thaddeus Martin
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

Carter Schonwald
Cool. What apis in base should move to use Addr from fake pointer ? Cause just adding it in isolation seems lame! 

I guess I’m just trying to say “what would the impact on base, if every fake Ptr was moved to be Addr?” Because it’s not something which should be done by halves. 

1) what apis would be changed?

2) what internal things would be changed albeit not Api visible 

3). Address arithmetic for Addr is very different from addres arithmetic on larger than word8 size storable values, is there anything which would move representations where the change to byte indexed would change the calculations ?


If we can layout what the impact / scope of changes needed for these and other considerations, I guess I’d be all for it. Assuming there’s the corresponding interest in executing changes. (I just have this worry in my head that it might be one of those icebergs.. like the split base effort )



On Thu, Oct 25, 2018 at 11:33 PM David Feuer <[hidden email]> wrote:
On Thu, Oct 25, 2018, 11:28 PM Carter Schonwald <[hidden email]> wrote:
Pretending we’re talking about this with storable as our example semantics : 

Ptr Void 
Corresponds to a memory address you don’t want to read or write to.

This is not so easy to think about (there's not much utility in such a type). Perhaps Ptr Void is a reasonable type for pointers known to be null or outside the address space, but I'm not sure.


Ptr () corresponds to a memory location that’s pretty boring to read / write to

Yes! In other words, it's *not* what people should be using for a pointer to an arbitrary non-Haskell address. That's precisely what Addr is for.


On Thu, Oct 25, 2018 at 11:22 PM Carter Schonwald <[hidden email]> wrote:
... when is a valid pointer not going to point at byte addressable memory on memory architectures ghc can support or target? 

On Thu, Oct 25, 2018 at 8:27 PM Daniel Cartwright <[hidden email]> wrote:
Now, one could argue that `Ptr ()` isn't a lie, it sort of reads like C's void pointer. But surely something like `Ptr Word8` is a lie, when it is not actually a Ptr to Word8 values.

On Thu, Oct 25, 2018 at 8:11 PM Daniel Cartwright <[hidden email]> wrote:
yes, only the type and its instances should be moved as far as i'm aware.

Also, it's more than just base.

in GHC.Stats, the foreign import "getRTSStats" has `Ptr () -> IO ()`, this Ptr () is also a lie

These are just off the top of my head, there are more


On Thu, Oct 25, 2018 at 6:46 PM Carter Schonwald <[hidden email]> wrote:
hrmm, what are the pieces of base that are using Ptr when they really should be using Addr? This would help me understand what would be made better in base :) 

On Thu, Oct 25, 2018 at 6:19 PM David Feuer <[hidden email]> wrote:
We shouldn't really need to move anything into base except Addr and its base instances.

On Oct 25, 2018 5:59 PM, "Carter Schonwald" <[hidden email]> wrote:
Indeed.  The monad transformer instances for primmonad need to live in primmonad OR transformers to avoid orphans. 

Either way, unless transformers moves into base (unlikely), no way anything using prim monad will. 

On Thu, Oct 25, 2018 at 3:34 PM Andrew Martin <[hidden email]> wrote:
I like the idea of moving the type Addr into base. But we cannot move the entire module since it has functions that talk about PrimMonad, and we definitely don't want to move that into base.

On Thu, Oct 25, 2018 at 11:25 AM Daniel Cartwright <[hidden email]> wrote:
Motivation: There are a lot of places in base where 'Ptr a' is used in place of 'Addr', because in base there is no 'Addr', only 'Addr#'. The problem lies in the fact that many of these uses of 'Ptr a' are lying; the 'a' value is meaningless. Authors of functions therein have used things like 'Ptr ()', 'Ptr Word8', 'Ptr a', but these types do not mean what they say they mean - they're just Addr. There are probably other motivations for this that I can't think of off the top of my head right now.
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries


--
-Andrew Thaddeus Martin
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

Henning Thielemann
In reply to this post by David Feuer

On Thu, 25 Oct 2018, David Feuer wrote:

> Ptr Word8 is not (just) a pointer to byte-addressable memory. It's
> specifically a pointer to something representing an 8-bit unsigned
> integer. If you use a Ptr Word8 for the address of a floating point
> value, then you are *wrong* (or doing something very weird, anyway). To
> quote the documentation,
>
> A value of type Ptr a represents a pointer to an object, or an array of
> objects, which may be marshalled to or from Haskell values of type a.

Interesting observations.

There are the Storable methods

peekByteOff :: Ptr b -> Int -> IO a
pokeByteOff :: Ptr b -> Int -> a -> IO ()

They ignore the target types of their pointers. Should be Addr, then, too?

And if we are touching Storable class, how about passing Proxy's to sizeOf
and alignment instead of undefined values? Maybe we should add new methods
to Storable class with default implementations that redirect to the old
methods.
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

David Feuer
While we're in that realm, it would be nice to find a mechanism that will explain what we need for both Storable (stick something at an Addr address) and Primitive (stick something in a MutableByteArray). The current situation is rather annoying. Can the compiler help?

On Fri, Oct 26, 2018, 5:15 AM Henning Thielemann <[hidden email]> wrote:

On Thu, 25 Oct 2018, David Feuer wrote:

> Ptr Word8 is not (just) a pointer to byte-addressable memory. It's
> specifically a pointer to something representing an 8-bit unsigned
> integer. If you use a Ptr Word8 for the address of a floating point
> value, then you are *wrong* (or doing something very weird, anyway). To
> quote the documentation,
>
> A value of type Ptr a represents a pointer to an object, or an array of
> objects, which may be marshalled to or from Haskell values of type a.

Interesting observations.

There are the Storable methods

peekByteOff :: Ptr b -> Int -> IO a
pokeByteOff :: Ptr b -> Int -> a -> IO ()

They ignore the target types of their pointers. Should be Addr, then, too?

And if we are touching Storable class, how about passing Proxy's to sizeOf
and alignment instead of undefined values? Maybe we should add new methods
to Storable class with default implementations that redirect to the old
methods.

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

Carter Schonwald
The law of Prim is “whatever is best for vector ”, which is really about making sure it’s easy to write soa and aos memory layouts representations for vector. It has nothing to do with storable.  Storable is for fixed size c struct mappable values.  That they do similar things api wise is a trick rather than a connection. 

Either way that’s orthogonal to Ptr and Adr. 

On Fri, Oct 26, 2018 at 6:16 AM David Feuer <[hidden email]> wrote:
While we're in that realm, it would be nice to find a mechanism that will explain what we need for both Storable (stick something at an Addr address) and Primitive (stick something in a MutableByteArray). The current situation is rather annoying. Can the compiler help?

On Fri, Oct 26, 2018, 5:15 AM Henning Thielemann <[hidden email]> wrote:

On Thu, 25 Oct 2018, David Feuer wrote:

> Ptr Word8 is not (just) a pointer to byte-addressable memory. It's
> specifically a pointer to something representing an 8-bit unsigned
> integer. If you use a Ptr Word8 for the address of a floating point
> value, then you are *wrong* (or doing something very weird, anyway). To
> quote the documentation,
>
> A value of type Ptr a represents a pointer to an object, or an array of
> objects, which may be marshalled to or from Haskell values of type a.

Interesting observations.

There are the Storable methods

peekByteOff :: Ptr b -> Int -> IO a
pokeByteOff :: Ptr b -> Int -> a -> IO ()

They ignore the target types of their pointers. Should be Addr, then, too?

And if we are touching Storable class, how about passing Proxy's to sizeOf
and alignment instead of undefined values? Maybe we should add new methods
to Storable class with default implementations that redirect to the old
methods.

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

Carter Schonwald
In reply to this post by Carter Schonwald
Daniel or David, would either of you be interested/willing to do the legwork on this patch wise (subject to sanity checking whats the impact surface area?)

On Fri, Oct 26, 2018 at 12:04 AM Carter Schonwald <[hidden email]> wrote:
Cool. What apis in base should move to use Addr from fake pointer ? Cause just adding it in isolation seems lame! 

I guess I’m just trying to say “what would the impact on base, if every fake Ptr was moved to be Addr?” Because it’s not something which should be done by halves. 

1) what apis would be changed?

2) what internal things would be changed albeit not Api visible 

3). Address arithmetic for Addr is very different from addres arithmetic on larger than word8 size storable values, is there anything which would move representations where the change to byte indexed would change the calculations ?


If we can layout what the impact / scope of changes needed for these and other considerations, I guess I’d be all for it. Assuming there’s the corresponding interest in executing changes. (I just have this worry in my head that it might be one of those icebergs.. like the split base effort )



On Thu, Oct 25, 2018 at 11:33 PM David Feuer <[hidden email]> wrote:
On Thu, Oct 25, 2018, 11:28 PM Carter Schonwald <[hidden email]> wrote:
Pretending we’re talking about this with storable as our example semantics : 

Ptr Void 
Corresponds to a memory address you don’t want to read or write to.

This is not so easy to think about (there's not much utility in such a type). Perhaps Ptr Void is a reasonable type for pointers known to be null or outside the address space, but I'm not sure.


Ptr () corresponds to a memory location that’s pretty boring to read / write to

Yes! In other words, it's *not* what people should be using for a pointer to an arbitrary non-Haskell address. That's precisely what Addr is for.


On Thu, Oct 25, 2018 at 11:22 PM Carter Schonwald <[hidden email]> wrote:
... when is a valid pointer not going to point at byte addressable memory on memory architectures ghc can support or target? 

On Thu, Oct 25, 2018 at 8:27 PM Daniel Cartwright <[hidden email]> wrote:
Now, one could argue that `Ptr ()` isn't a lie, it sort of reads like C's void pointer. But surely something like `Ptr Word8` is a lie, when it is not actually a Ptr to Word8 values.

On Thu, Oct 25, 2018 at 8:11 PM Daniel Cartwright <[hidden email]> wrote:
yes, only the type and its instances should be moved as far as i'm aware.

Also, it's more than just base.

in GHC.Stats, the foreign import "getRTSStats" has `Ptr () -> IO ()`, this Ptr () is also a lie

These are just off the top of my head, there are more


On Thu, Oct 25, 2018 at 6:46 PM Carter Schonwald <[hidden email]> wrote:
hrmm, what are the pieces of base that are using Ptr when they really should be using Addr? This would help me understand what would be made better in base :) 

On Thu, Oct 25, 2018 at 6:19 PM David Feuer <[hidden email]> wrote:
We shouldn't really need to move anything into base except Addr and its base instances.

On Oct 25, 2018 5:59 PM, "Carter Schonwald" <[hidden email]> wrote:
Indeed.  The monad transformer instances for primmonad need to live in primmonad OR transformers to avoid orphans. 

Either way, unless transformers moves into base (unlikely), no way anything using prim monad will. 

On Thu, Oct 25, 2018 at 3:34 PM Andrew Martin <[hidden email]> wrote:
I like the idea of moving the type Addr into base. But we cannot move the entire module since it has functions that talk about PrimMonad, and we definitely don't want to move that into base.

On Thu, Oct 25, 2018 at 11:25 AM Daniel Cartwright <[hidden email]> wrote:
Motivation: There are a lot of places in base where 'Ptr a' is used in place of 'Addr', because in base there is no 'Addr', only 'Addr#'. The problem lies in the fact that many of these uses of 'Ptr a' are lying; the 'a' value is meaningless. Authors of functions therein have used things like 'Ptr ()', 'Ptr Word8', 'Ptr a', but these types do not mean what they say they mean - they're just Addr. There are probably other motivations for this that I can't think of off the top of my head right now.
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries


--
-Andrew Thaddeus Martin
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

chessai .
I would, yeah. Should the next version of `primitive` just re-export `Addr` from base in `Data.Primitive.Addr`?

On Fri, Oct 26, 2018 at 10:14 AM Carter Schonwald <[hidden email]> wrote:
Daniel or David, would either of you be interested/willing to do the legwork on this patch wise (subject to sanity checking whats the impact surface area?)

On Fri, Oct 26, 2018 at 12:04 AM Carter Schonwald <[hidden email]> wrote:
Cool. What apis in base should move to use Addr from fake pointer ? Cause just adding it in isolation seems lame! 

I guess I’m just trying to say “what would the impact on base, if every fake Ptr was moved to be Addr?” Because it’s not something which should be done by halves. 

1) what apis would be changed?

2) what internal things would be changed albeit not Api visible 

3). Address arithmetic for Addr is very different from addres arithmetic on larger than word8 size storable values, is there anything which would move representations where the change to byte indexed would change the calculations ?


If we can layout what the impact / scope of changes needed for these and other considerations, I guess I’d be all for it. Assuming there’s the corresponding interest in executing changes. (I just have this worry in my head that it might be one of those icebergs.. like the split base effort )



On Thu, Oct 25, 2018 at 11:33 PM David Feuer <[hidden email]> wrote:
On Thu, Oct 25, 2018, 11:28 PM Carter Schonwald <[hidden email]> wrote:
Pretending we’re talking about this with storable as our example semantics : 

Ptr Void 
Corresponds to a memory address you don’t want to read or write to.

This is not so easy to think about (there's not much utility in such a type). Perhaps Ptr Void is a reasonable type for pointers known to be null or outside the address space, but I'm not sure.


Ptr () corresponds to a memory location that’s pretty boring to read / write to

Yes! In other words, it's *not* what people should be using for a pointer to an arbitrary non-Haskell address. That's precisely what Addr is for.


On Thu, Oct 25, 2018 at 11:22 PM Carter Schonwald <[hidden email]> wrote:
... when is a valid pointer not going to point at byte addressable memory on memory architectures ghc can support or target? 

On Thu, Oct 25, 2018 at 8:27 PM Daniel Cartwright <[hidden email]> wrote:
Now, one could argue that `Ptr ()` isn't a lie, it sort of reads like C's void pointer. But surely something like `Ptr Word8` is a lie, when it is not actually a Ptr to Word8 values.

On Thu, Oct 25, 2018 at 8:11 PM Daniel Cartwright <[hidden email]> wrote:
yes, only the type and its instances should be moved as far as i'm aware.

Also, it's more than just base.

in GHC.Stats, the foreign import "getRTSStats" has `Ptr () -> IO ()`, this Ptr () is also a lie

These are just off the top of my head, there are more


On Thu, Oct 25, 2018 at 6:46 PM Carter Schonwald <[hidden email]> wrote:
hrmm, what are the pieces of base that are using Ptr when they really should be using Addr? This would help me understand what would be made better in base :) 

On Thu, Oct 25, 2018 at 6:19 PM David Feuer <[hidden email]> wrote:
We shouldn't really need to move anything into base except Addr and its base instances.

On Oct 25, 2018 5:59 PM, "Carter Schonwald" <[hidden email]> wrote:
Indeed.  The monad transformer instances for primmonad need to live in primmonad OR transformers to avoid orphans. 

Either way, unless transformers moves into base (unlikely), no way anything using prim monad will. 

On Thu, Oct 25, 2018 at 3:34 PM Andrew Martin <[hidden email]> wrote:
I like the idea of moving the type Addr into base. But we cannot move the entire module since it has functions that talk about PrimMonad, and we definitely don't want to move that into base.

On Thu, Oct 25, 2018 at 11:25 AM Daniel Cartwright <[hidden email]> wrote:
Motivation: There are a lot of places in base where 'Ptr a' is used in place of 'Addr', because in base there is no 'Addr', only 'Addr#'. The problem lies in the fact that many of these uses of 'Ptr a' are lying; the 'a' value is meaningless. Authors of functions therein have used things like 'Ptr ()', 'Ptr Word8', 'Ptr a', but these types do not mean what they say they mean - they're just Addr. There are probably other motivations for this that I can't think of off the top of my head right now.
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries


--
-Andrew Thaddeus Martin
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

chessai .
Also, where in base should Addr go?

On Fri, Oct 26, 2018 at 10:15 AM Daniel Cartwright <[hidden email]> wrote:
I would, yeah. Should the next version of `primitive` just re-export `Addr` from base in `Data.Primitive.Addr`?

On Fri, Oct 26, 2018 at 10:14 AM Carter Schonwald <[hidden email]> wrote:
Daniel or David, would either of you be interested/willing to do the legwork on this patch wise (subject to sanity checking whats the impact surface area?)

On Fri, Oct 26, 2018 at 12:04 AM Carter Schonwald <[hidden email]> wrote:
Cool. What apis in base should move to use Addr from fake pointer ? Cause just adding it in isolation seems lame! 

I guess I’m just trying to say “what would the impact on base, if every fake Ptr was moved to be Addr?” Because it’s not something which should be done by halves. 

1) what apis would be changed?

2) what internal things would be changed albeit not Api visible 

3). Address arithmetic for Addr is very different from addres arithmetic on larger than word8 size storable values, is there anything which would move representations where the change to byte indexed would change the calculations ?


If we can layout what the impact / scope of changes needed for these and other considerations, I guess I’d be all for it. Assuming there’s the corresponding interest in executing changes. (I just have this worry in my head that it might be one of those icebergs.. like the split base effort )



On Thu, Oct 25, 2018 at 11:33 PM David Feuer <[hidden email]> wrote:
On Thu, Oct 25, 2018, 11:28 PM Carter Schonwald <[hidden email]> wrote:
Pretending we’re talking about this with storable as our example semantics : 

Ptr Void 
Corresponds to a memory address you don’t want to read or write to.

This is not so easy to think about (there's not much utility in such a type). Perhaps Ptr Void is a reasonable type for pointers known to be null or outside the address space, but I'm not sure.


Ptr () corresponds to a memory location that’s pretty boring to read / write to

Yes! In other words, it's *not* what people should be using for a pointer to an arbitrary non-Haskell address. That's precisely what Addr is for.


On Thu, Oct 25, 2018 at 11:22 PM Carter Schonwald <[hidden email]> wrote:
... when is a valid pointer not going to point at byte addressable memory on memory architectures ghc can support or target? 

On Thu, Oct 25, 2018 at 8:27 PM Daniel Cartwright <[hidden email]> wrote:
Now, one could argue that `Ptr ()` isn't a lie, it sort of reads like C's void pointer. But surely something like `Ptr Word8` is a lie, when it is not actually a Ptr to Word8 values.

On Thu, Oct 25, 2018 at 8:11 PM Daniel Cartwright <[hidden email]> wrote:
yes, only the type and its instances should be moved as far as i'm aware.

Also, it's more than just base.

in GHC.Stats, the foreign import "getRTSStats" has `Ptr () -> IO ()`, this Ptr () is also a lie

These are just off the top of my head, there are more


On Thu, Oct 25, 2018 at 6:46 PM Carter Schonwald <[hidden email]> wrote:
hrmm, what are the pieces of base that are using Ptr when they really should be using Addr? This would help me understand what would be made better in base :) 

On Thu, Oct 25, 2018 at 6:19 PM David Feuer <[hidden email]> wrote:
We shouldn't really need to move anything into base except Addr and its base instances.

On Oct 25, 2018 5:59 PM, "Carter Schonwald" <[hidden email]> wrote:
Indeed.  The monad transformer instances for primmonad need to live in primmonad OR transformers to avoid orphans. 

Either way, unless transformers moves into base (unlikely), no way anything using prim monad will. 

On Thu, Oct 25, 2018 at 3:34 PM Andrew Martin <[hidden email]> wrote:
I like the idea of moving the type Addr into base. But we cannot move the entire module since it has functions that talk about PrimMonad, and we definitely don't want to move that into base.

On Thu, Oct 25, 2018 at 11:25 AM Daniel Cartwright <[hidden email]> wrote:
Motivation: There are a lot of places in base where 'Ptr a' is used in place of 'Addr', because in base there is no 'Addr', only 'Addr#'. The problem lies in the fact that many of these uses of 'Ptr a' are lying; the 'a' value is meaningless. Authors of functions therein have used things like 'Ptr ()', 'Ptr Word8', 'Ptr a', but these types do not mean what they say they mean - they're just Addr. There are probably other motivations for this that I can't think of off the top of my head right now.
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries


--
-Andrew Thaddeus Martin
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
12345