Skip to content

Conversation

ruifengx
Copy link
Contributor

This is a follow up for the DoNotUnbox* family of newtype DerivingVia wrappers (#508). It allows treating Storable vectors as unboxed vectors. My personal use case is combining parallel arrays received from C FFI into a single Vector. I left a comment about this in #503, and did not get a response, but I still think this is a nice thing to have in vector.

I followed the implementation for UnboxViaPrim and named this new wrapper UnboxViaStorable. While working on this PR, I noticed that the documentation for UnboxViaPrim named the vector for Foo [M]V_Int instead of [M]V_Foo, so I also corrected them.

As a minor detail, the previous PR imports Data.Vector.Strict qualified as S, so I cannot use S for Storable and had to use St. I can change it if there is a preferred naming scheme for qualified imports.

@ruifengx
Copy link
Contributor Author

I see some doctests errors and tried to fix them. Unfortunately, I cannot run doctests locally because it reports a lot of "Could not find module" errors, so I did it based on the logs from GitHub CI. After fixing the obvious typos, I am somewhat stuck right now because I do not quite understand how the module grouping in doctests.hs file works (I see that only 8.10.7 and 9.0.2 are still failing).

@Shimuuar
Copy link
Contributor

I think PR is fine in general. We have support for deriving unboxed instances using primitive vectors, variants of boxed vector. No reason to not to add storable into the mix.

I'll try to look why doctests fail on GHC 9.0,8.10

ruifengx and others added 4 commits January 17, 2025 16:42
 - Fix typos in documentation for UnboxViaStorable
 - Add implementation of unboxing newtypes for Storable data
Doctests do awful job checking it. Constructor may be in scope for doctest and
not in scope for client code
@Shimuuar
Copy link
Contributor

As it turns out failure was genuine. V_UnboxViaStorable must be in scope for deriving to work. Doctests just happen to work. I added tests to check that deriving actually works

@ruifengx
Copy link
Contributor Author

Thanks, I see the problem now. doctest "opens" the module before running (in the same way as :m *SomeModule in GHCi), making all internal definitions available, which presumably have made the tests pass for most compiler versions.

@Shimuuar Shimuuar merged commit 04194a0 into haskell:master Jan 17, 2025
26 checks passed
@ruifengx ruifengx deleted the unboxed-storable branch January 17, 2025 15:54
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants