I think it would have been natural, here, to convert to an unlifted immutable array. And post-convert to Vector in the unlifted case instead.

See unsafeFreezeArray#

MVector's constructor is as follows:

data MVector s a = MVector {-# UNPACK #-} !Int
                           {-# UNPACK #-} !Int
                           {-# UNPACK #-} !(MutableArray s a)
        deriving ( Typeable )

That MutableArray is from the primitive package:

-- | Mutable boxed arrays associated with a primitive state token.
data MutableArray s a = MutableArray
  { marray# :: MutableArray# s a }
  deriving ( Typeable )

So, that forces us to go through MutableArray. The Vector constructor work as you mentioned:

data Vector a = Vector {-# UNPACK #-} !Int
                       {-# UNPACK #-} !Int
                       {-# UNPACK #-} !(Array a)
        deriving ( Typeable )

And it'd be ideal to use it, however that constructor is not exported.

This is quite unfortunate indeed. It's the one type in vector which isn't exported.

Let me formulate a plan: do freeze to Array# here. To implement the conversion Array# -> Vector, use unsafeThaw# together with your present implementation based on MVector. But move that code to the lifted array module.

Then, next week, let us propose some kind of PR to the vector library so that we can use the Vector constructor directly in the future.

I now understand why you are asking for this, and I agree. Freezing an unlifted mutable array to an unlifted immutable array makes sense. I did the change.

Which caused unlifted arrays freeze function to have a different signature:

freeze :: (GHC.Array# a -> b) -> Array# a #-> Ur b

Because I couldn't put an unlifted type inside a Ur. We are using the same pattern on unArray# function too, so I think it is fine.

Yes, it's safe. Ur a is isomorphic to forall k. (a -> k) #-> k (exercise!).

Ultimately, we probably want to expose an unlifted unrestricted thing. There is no obstacle except time and syntax.

Here is the corresponding issue, by the way: https://gitlab.haskell.org/ghc/ghc/-/issues/18490 .

Let's make an issue in our tracker to fix this. And we'll contribute upstream some way. After milestone 1.

I opened: #214

I think this is correct because of the source of the MVector instance for MVector.