emilypi
Add Unboxed variant
Other variants (storable, primitive) would be nice bonus, but Unbox’d vector is often a must thing
I've been talking about this with @cartazio. I think next up will be Data.Vector.NonEmpty.Unboxed (and hopefully Storable after that), but we were thinking we'd skip Primitive.
The library's at a good state where we can get all the Vector instances we want, so this shouldn't be too much trouble when I have a weekend to hack on it.
you can get all three via having a newtype NonEmptyV v a= NEV (v a) ; newtype NonEmptyMV mv s a = NEMV (mv s a) and then having an the various vector instances etc just pass through plus
by hand or derivingvia to get
instance Vector v a => Vector (NonEmptyV v) v a etc
I cannot parse the previous comment.
I also would think very hard whether having Vector (NonEmptyVector a) a instance is all that useful, compared to an opportunity for someone to shoot themselves into a foot.
That's definitely a possiblity. I'll write it out and see if there are any edge cases we have to worry about.
I agree that maybe the instance Would have footguns. But it would reduce the engineering surface area for all the exposed methods
My one worry would be that it would introduce upstream variability which could break downstream invariants. It's probably not the case since the Vector class API doesn't really deal much with container structure, but it's still a worry that I'd have to decide to commit to while doing some investigatory implementations.
Speaking as upstream: what are possible upstream variations that are physically possible? And not otherwise already possible with any approach you do for your layer?
I don't know! I don't know the Vector api well enough to say. If you tell me there's no chance I'll believe you and implement it.
Let’s find an hour to sit down with some tea and it’ll be done by the end. It’s really much simpler than you expect I think ;)