Improved interface to UArray

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

Improved interface to UArray

Zemyla
It's currently hard to describe that a type should be usable with UArray or IOUArray, and almost impossible to describe without QualifiedConstraints that it should be usable with STUArray. And it's actually impossible to use GeneralizedNewtypeDeriving to derive new instances of IArray or MArray. It also means that it's difficult to keep the three sets of instances in sync.

Therefore, there should be (taking inspiration from primitive) a class that describes types which can be used in unboxed arrays. It'd be something along the lines of:

class Unboxed e where
  unsafeNewUArray :: Int# -> e -> State# s -> (# State# s, MutableByteArray# s #)
  unsafeNewUArray_ :: Const (Int# -> State# s -> (# State# s, MutableByteArray# s #)) e
  unsafeReadUArray :: MutableByteArray# s -> Int# -> State# s -> (# State# s, e #)
  unsafeWriteUArray :: MutableByteArray# s -> Int# -> e -> State# s -> State# s
  unsafeIndexUArray :: ByteArray# -> Int# -> e

And then the instances for UArray, STUArray, and IOUArray would be:

instance Unboxed e => IArray UArray e where ...
instance Unboxed e => MArray IOUArray e IO where ...
instance Unboxed e => MArray (STUArray s) e (ST s) where ...

Incidentally, this also means it'd be less effort to add instances like Unboxed CInt, Unboxed a => Unboxed (Complex a), and Unboxed Ordering.

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

Re: Improved interface to UArray

Carter Schonwald
Hey Zemyla!
one fuzzy question i have, and perhaps you have a perspective on this, would/could the PrimMonad machinery in primitive help simplify / clean up stuff here too?

On Mon, Feb 24, 2020 at 9:46 AM Zemyla <[hidden email]> wrote:
It's currently hard to describe that a type should be usable with UArray or IOUArray, and almost impossible to describe without QualifiedConstraints that it should be usable with STUArray. And it's actually impossible to use GeneralizedNewtypeDeriving to derive new instances of IArray or MArray. It also means that it's difficult to keep the three sets of instances in sync.

Therefore, there should be (taking inspiration from primitive) a class that describes types which can be used in unboxed arrays. It'd be something along the lines of:

class Unboxed e where
  unsafeNewUArray :: Int# -> e -> State# s -> (# State# s, MutableByteArray# s #)
  unsafeNewUArray_ :: Const (Int# -> State# s -> (# State# s, MutableByteArray# s #)) e
  unsafeReadUArray :: MutableByteArray# s -> Int# -> State# s -> (# State# s, e #)
  unsafeWriteUArray :: MutableByteArray# s -> Int# -> e -> State# s -> State# s
  unsafeIndexUArray :: ByteArray# -> Int# -> e

And then the instances for UArray, STUArray, and IOUArray would be:

instance Unboxed e => IArray UArray e where ...
instance Unboxed e => MArray IOUArray e IO where ...
instance Unboxed e => MArray (STUArray s) e (ST s) where ...

Incidentally, this also means it'd be less effort to add instances like Unboxed CInt, Unboxed a => Unboxed (Complex a), and Unboxed Ordering.
_______________________________________________
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: Improved interface to UArray

Zemyla
We should probably use something similar, but I don't think a dependency on primitive is a good idea.

On Tue, Mar 3, 2020, 14:28 Carter Schonwald <[hidden email]> wrote:
Hey Zemyla!
one fuzzy question i have, and perhaps you have a perspective on this, would/could the PrimMonad machinery in primitive help simplify / clean up stuff here too?

On Mon, Feb 24, 2020 at 9:46 AM Zemyla <[hidden email]> wrote:
It's currently hard to describe that a type should be usable with UArray or IOUArray, and almost impossible to describe without QualifiedConstraints that it should be usable with STUArray. And it's actually impossible to use GeneralizedNewtypeDeriving to derive new instances of IArray or MArray. It also means that it's difficult to keep the three sets of instances in sync.

Therefore, there should be (taking inspiration from primitive) a class that describes types which can be used in unboxed arrays. It'd be something along the lines of:

class Unboxed e where
  unsafeNewUArray :: Int# -> e -> State# s -> (# State# s, MutableByteArray# s #)
  unsafeNewUArray_ :: Const (Int# -> State# s -> (# State# s, MutableByteArray# s #)) e
  unsafeReadUArray :: MutableByteArray# s -> Int# -> State# s -> (# State# s, e #)
  unsafeWriteUArray :: MutableByteArray# s -> Int# -> e -> State# s -> State# s
  unsafeIndexUArray :: ByteArray# -> Int# -> e

And then the instances for UArray, STUArray, and IOUArray would be:

instance Unboxed e => IArray UArray e where ...
instance Unboxed e => MArray IOUArray e IO where ...
instance Unboxed e => MArray (STUArray s) e (ST s) where ...

Incidentally, this also means it'd be less effort to add instances like Unboxed CInt, Unboxed a => Unboxed (Complex a), and Unboxed Ordering.
_______________________________________________
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: Improved interface to UArray

chessai .
Zemlya, could you expound on why you think a primitive dependency is a bad idea? I'm just not sure what reasons you have in mind.

Thanks 

On Tue, Mar 3, 2020, 12:31 PM Zemyla <[hidden email]> wrote:
We should probably use something similar, but I don't think a dependency on primitive is a good idea.

On Tue, Mar 3, 2020, 14:28 Carter Schonwald <[hidden email]> wrote:
Hey Zemyla!
one fuzzy question i have, and perhaps you have a perspective on this, would/could the PrimMonad machinery in primitive help simplify / clean up stuff here too?

On Mon, Feb 24, 2020 at 9:46 AM Zemyla <[hidden email]> wrote:
It's currently hard to describe that a type should be usable with UArray or IOUArray, and almost impossible to describe without QualifiedConstraints that it should be usable with STUArray. And it's actually impossible to use GeneralizedNewtypeDeriving to derive new instances of IArray or MArray. It also means that it's difficult to keep the three sets of instances in sync.

Therefore, there should be (taking inspiration from primitive) a class that describes types which can be used in unboxed arrays. It'd be something along the lines of:

class Unboxed e where
  unsafeNewUArray :: Int# -> e -> State# s -> (# State# s, MutableByteArray# s #)
  unsafeNewUArray_ :: Const (Int# -> State# s -> (# State# s, MutableByteArray# s #)) e
  unsafeReadUArray :: MutableByteArray# s -> Int# -> State# s -> (# State# s, e #)
  unsafeWriteUArray :: MutableByteArray# s -> Int# -> e -> State# s -> State# s
  unsafeIndexUArray :: ByteArray# -> Int# -> e

And then the instances for UArray, STUArray, and IOUArray would be:

instance Unboxed e => IArray UArray e where ...
instance Unboxed e => MArray IOUArray e IO where ...
instance Unboxed e => MArray (STUArray s) e (ST s) where ...

Incidentally, this also means it'd be less effort to add instances like Unboxed CInt, Unboxed a => Unboxed (Complex a), and Unboxed Ordering.
_______________________________________________
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: Improved interface to UArray

Zemyla
Because a lot of the stuff is defined in GHC.Arr, in base. Also, the Prim instance for Bool is different than the UArray instance for Bool.

On Tue, Mar 3, 2020, 14:56 chessai . <[hidden email]> wrote:
Zemlya, could you expound on why you think a primitive dependency is a bad idea? I'm just not sure what reasons you have in mind.

Thanks 

On Tue, Mar 3, 2020, 12:31 PM Zemyla <[hidden email]> wrote:
We should probably use something similar, but I don't think a dependency on primitive is a good idea.

On Tue, Mar 3, 2020, 14:28 Carter Schonwald <[hidden email]> wrote:
Hey Zemyla!
one fuzzy question i have, and perhaps you have a perspective on this, would/could the PrimMonad machinery in primitive help simplify / clean up stuff here too?

On Mon, Feb 24, 2020 at 9:46 AM Zemyla <[hidden email]> wrote:
It's currently hard to describe that a type should be usable with UArray or IOUArray, and almost impossible to describe without QualifiedConstraints that it should be usable with STUArray. And it's actually impossible to use GeneralizedNewtypeDeriving to derive new instances of IArray or MArray. It also means that it's difficult to keep the three sets of instances in sync.

Therefore, there should be (taking inspiration from primitive) a class that describes types which can be used in unboxed arrays. It'd be something along the lines of:

class Unboxed e where
  unsafeNewUArray :: Int# -> e -> State# s -> (# State# s, MutableByteArray# s #)
  unsafeNewUArray_ :: Const (Int# -> State# s -> (# State# s, MutableByteArray# s #)) e
  unsafeReadUArray :: MutableByteArray# s -> Int# -> State# s -> (# State# s, e #)
  unsafeWriteUArray :: MutableByteArray# s -> Int# -> e -> State# s -> State# s
  unsafeIndexUArray :: ByteArray# -> Int# -> e

And then the instances for UArray, STUArray, and IOUArray would be:

instance Unboxed e => IArray UArray e where ...
instance Unboxed e => MArray IOUArray e IO where ...
instance Unboxed e => MArray (STUArray s) e (ST s) where ...

Incidentally, this also means it'd be less effort to add instances like Unboxed CInt, Unboxed a => Unboxed (Complex a), and Unboxed Ordering.
_______________________________________________
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: Improved interface to UArray

Carter Schonwald
I meant specifically using PrimMonad, rather than the prim array facilities, to write the instances

On Tue, Mar 3, 2020 at 5:14 PM Zemyla <[hidden email]> wrote:
Because a lot of the stuff is defined in GHC.Arr, in base. Also, the Prim instance for Bool is different than the UArray instance for Bool.

On Tue, Mar 3, 2020, 14:56 chessai . <[hidden email]> wrote:
Zemlya, could you expound on why you think a primitive dependency is a bad idea? I'm just not sure what reasons you have in mind.

Thanks 

On Tue, Mar 3, 2020, 12:31 PM Zemyla <[hidden email]> wrote:
We should probably use something similar, but I don't think a dependency on primitive is a good idea.

On Tue, Mar 3, 2020, 14:28 Carter Schonwald <[hidden email]> wrote:
Hey Zemyla!
one fuzzy question i have, and perhaps you have a perspective on this, would/could the PrimMonad machinery in primitive help simplify / clean up stuff here too?

On Mon, Feb 24, 2020 at 9:46 AM Zemyla <[hidden email]> wrote:
It's currently hard to describe that a type should be usable with UArray or IOUArray, and almost impossible to describe without QualifiedConstraints that it should be usable with STUArray. And it's actually impossible to use GeneralizedNewtypeDeriving to derive new instances of IArray or MArray. It also means that it's difficult to keep the three sets of instances in sync.

Therefore, there should be (taking inspiration from primitive) a class that describes types which can be used in unboxed arrays. It'd be something along the lines of:

class Unboxed e where
  unsafeNewUArray :: Int# -> e -> State# s -> (# State# s, MutableByteArray# s #)
  unsafeNewUArray_ :: Const (Int# -> State# s -> (# State# s, MutableByteArray# s #)) e
  unsafeReadUArray :: MutableByteArray# s -> Int# -> State# s -> (# State# s, e #)
  unsafeWriteUArray :: MutableByteArray# s -> Int# -> e -> State# s -> State# s
  unsafeIndexUArray :: ByteArray# -> Int# -> e

And then the instances for UArray, STUArray, and IOUArray would be:

instance Unboxed e => IArray UArray e where ...
instance Unboxed e => MArray IOUArray e IO where ...
instance Unboxed e => MArray (STUArray s) e (ST s) where ...

Incidentally, this also means it'd be less effort to add instances like Unboxed CInt, Unboxed a => Unboxed (Complex a), and Unboxed Ordering.
_______________________________________________
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: Improved interface to UArray

Carter Schonwald
looking at current base, https://downloads.haskell.org/ghc/latest/docs/html/libraries/base-4.13.0.0/GHC-Arr.html
it seems (naively to me) that nothing precludes the array package from using PrimMonad m => for the IO etc monad instances,
with zero impact on the interface as defined in base. Or am I missing something?

On Tue, Mar 3, 2020 at 6:39 PM Carter Schonwald <[hidden email]> wrote:
I meant specifically using PrimMonad, rather than the prim array facilities, to write the instances

On Tue, Mar 3, 2020 at 5:14 PM Zemyla <[hidden email]> wrote:
Because a lot of the stuff is defined in GHC.Arr, in base. Also, the Prim instance for Bool is different than the UArray instance for Bool.

On Tue, Mar 3, 2020, 14:56 chessai . <[hidden email]> wrote:
Zemlya, could you expound on why you think a primitive dependency is a bad idea? I'm just not sure what reasons you have in mind.

Thanks 

On Tue, Mar 3, 2020, 12:31 PM Zemyla <[hidden email]> wrote:
We should probably use something similar, but I don't think a dependency on primitive is a good idea.

On Tue, Mar 3, 2020, 14:28 Carter Schonwald <[hidden email]> wrote:
Hey Zemyla!
one fuzzy question i have, and perhaps you have a perspective on this, would/could the PrimMonad machinery in primitive help simplify / clean up stuff here too?

On Mon, Feb 24, 2020 at 9:46 AM Zemyla <[hidden email]> wrote:
It's currently hard to describe that a type should be usable with UArray or IOUArray, and almost impossible to describe without QualifiedConstraints that it should be usable with STUArray. And it's actually impossible to use GeneralizedNewtypeDeriving to derive new instances of IArray or MArray. It also means that it's difficult to keep the three sets of instances in sync.

Therefore, there should be (taking inspiration from primitive) a class that describes types which can be used in unboxed arrays. It'd be something along the lines of:

class Unboxed e where
  unsafeNewUArray :: Int# -> e -> State# s -> (# State# s, MutableByteArray# s #)
  unsafeNewUArray_ :: Const (Int# -> State# s -> (# State# s, MutableByteArray# s #)) e
  unsafeReadUArray :: MutableByteArray# s -> Int# -> State# s -> (# State# s, e #)
  unsafeWriteUArray :: MutableByteArray# s -> Int# -> e -> State# s -> State# s
  unsafeIndexUArray :: ByteArray# -> Int# -> e

And then the instances for UArray, STUArray, and IOUArray would be:

instance Unboxed e => IArray UArray e where ...
instance Unboxed e => MArray IOUArray e IO where ...
instance Unboxed e => MArray (STUArray s) e (ST s) where ...

Incidentally, this also means it'd be less effort to add instances like Unboxed CInt, Unboxed a => Unboxed (Complex a), and Unboxed Ordering.
_______________________________________________
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