-
Notifications
You must be signed in to change notification settings - Fork 58
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Consider making distinct types for pinned and unpinned arrays #405
Comments
I don't see a way to do this without breaking the API, and API stability is important for this library. I've thought before about what you suggest. Something like this (ignoring element polymorphism):
This is a fine API, but I don't see how to introduce this without breaking a bunch of programs that already use this library. |
Perhaps this would best fit into a separate library that provides thin wrappers over |
Another reason against making this the default is that it disallows mixing arrays with different pinnedness, e.g. arr = if makePinned then newPinnedByteArray 42 else newByteArray 42 This could be solved using existentials, but usually when using In most cases, you're only using unpinned arrays anyway (at least I never had the need to use pinned arrays), so this would probably be overkill. However, I'd be interested to know if people feel like such a type would actually be useful to them. |
I created a topic on the Haskell Discourse about this: https://discourse.haskell.org/t/distinguishing-pinned-and-unpinned-arrays-via-a-type-parameter/8443. |
The Discourse discussion came to the conclusion that one can just use |
I think you intended to write "pinned" but wrote "unpinned" instead. The arrays from |
There are operations that can't support unpinned arrays, but currently the types don't actually prevent such arrays from being provided. There are constructive operations that should be able to produce either pinned or unpinned arrays, but currently only exist for unpinned arrays, such as primArrayFromList (there's no pinnedPrimArrayFromList).
One potential option would be to make a type parameter that is a data kind, indicating Pinned or Unpinned. Then operations that apply to both can just leave that type parameter unspecified...
The text was updated successfully, but these errors were encountered: