Feature Request: Make underlying representations accessible

[axman6]

In the binary-serialise-cbor repo, there's been some discussion about the difficulty of being able to implement Serialise for Vectors which use more efficient representations of vectors than providing an array of structures in the encoded form. In well-typed/cborg#62 I had proposed making the underlying representation of Vectors accessible via an associated type (this isn't precise when compared to the current implementation but I hope gets the idea across):

class Vector v a where
    type VRepr v a :: *
    toVRepr :: v a -> VRepr v a
    fromVRepr :: VRepr v a -> Maybe (v a)
    ... -- The rest of the current Vector class

instance Vector v Int where
  type VRepr v Int = v Int -- this is certainly not correct

instance (Vector v a, Vector v b) => Vector v (a,b) where
    type VRepr v (a,b) = (Vector v a, Vector v b)
    -- Or perhaps?
    -- type VRepr v (a,b) = (VRepr v a, VRepr v b)
    toVRepr (V_M2 _ va vb) = (va,vb) -- AKA unzip
    ...

Which allows for defining instances for the primitive types and instances for things like (Serialise a, Serialise b) => Serialise (a,b) and we get the instances for Serialise (a,b), Serialise (Complex a) etc. essentially for free.

This is something I've run into a few times, where I wanted to take advantage of the underlying array of structures representation of Vectors without needing to know exactly which constructor was being used.

This is (obviously) not a very thorough proposal, I'm making it to spark discussion, and I'll be happy if the result is "no, because ... impossible ...", or "yes, we'll do this and change the major version".

[cartazio]

We're definitely in favor of providing the unwrapping for those products of unboxed vectors on a per type expose the constructor style fashion, but I don't think it needs or benefits from a type class around it, since we can only really expose the core family of reps for unboxed vector. This does seem to be specific to unboxed soa vectors, if you look at some of the other tickets I think you'll see some discussion about ways to expose representations in a internal style module or something. Would that suffice for those needs? Also when is that cbor package going onto hackage ?

…

On Thu, Jun 1, 2017 at 11:45 PM Alex Mason ***@***.***> wrote: In the (binary-serialise-cbor)[ https://github.com/well-typed/binary-serialise-cbor] repo, there's been some discussion about the difficulty of being able to implement Serialise for Vectors which use more efficient representations of vectors than providing an array of structures in the encoded form. In well-typed/cborg#62 <well-typed/cborg#62> I had proposed making the underlying representation of Vectors accessible via an associated type (this isn't precise when compared to the current implementation but I hope gets the idea across): class Vector v a where type VRepr v a :: * toVRepr :: v a -> VRepr v a fromVRepr :: VRepr v a -> Maybe (v a) ... -- The rest of the current Vector class instance Vector instance (Vector v a, Vector v b) => Vector v (a,b) where type VRepr v (a,b) = (Vector v a, Vector v b) toVRepr (V_M2 _ va vb) = (va,vb) -- AKA unzip ... Which allows for defining instances for the primitive types and instances for things like (Serialise a, Serialise b) => Serialise (a,b) and we get the instances for Serialise (a,b), Serialise (Complex a) etc. essentially for free. This is something I've run into a few times, where I wanted to take advantage of the underlying array of structures representation of Vectors without needing to know exactly which constructor was being used. This is (obviously) not a very thorough proposal, I'm making it to spark discussion, and I'll be happy if the result is "no, because ... impossible ...", or "yes, we'll do this and change the major version". — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#171>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAAQwh-mgnhBEXEoUh2wL2HgnGEW-QXqks5r_4VlgaJpZM4Nty_3> .

[axman6]

So my intent was to add the unwrapping features to the Vector class, or the type family which defines the structure of the representations. I'm just not sure what the best way to implement this would be.

The cbor package (now officially to be known as cborg) should be released by the first of July (hopefully).

[cartazio]

there is no such abstraction yet in vector, and it can't exist in general.

…

On Wed, Jun 21, 2017 at 9:29 PM, Alex Mason ***@***.***> wrote: So my intent was to add the unwrapping features to the Vector class, or the type family which defines the structure of the representations. I'm just not sure what the best way to implement this would be. The cbor package (now officially to be known as cborg) should be released by the first of July (hopefully). — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#171 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAAQwoHIF2SkvcZkCICIwWVIUY2UcW5Hks5sGcOJgaJpZM4Nty_3> .

[dolio]

Hmm...

It's been on my todo list for far too long to expose the constructors of various vector types. However, I hadn't thought of making an abstraction for it.

I guess my question is: is this actually any better than just having the constructors available? It doesn't seem like there is much hope for writing code that is abstract over the representation, because that can change with vector and element type, and all you have is the ability to convert between the vector and its underlying representation. Is there something in cborg that would make this more useful than it seems to me?

As far as exposing the internals goes in general, I'm for it.

[utdemir]

As far as exposing the internals goes in general, I'm for it.

I just wanted to mention that I would also appreciate being able to access the Vector constructor. We have an issue on linear-base, where we have a Array#, and going from that to a Vector is a bit annoying without having access to the Vector constructor.

[lehins]

@utdemir Going from Array# shouldn't be a problem with this new fromArray conversion function.