-
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
fromList for mutable arrays #413
Comments
I think this is pretty reasonable, particularly because the variant returning a mutable array is the more fundamental one. The immutable variants are just the mutable variants but with the result frozen:
I'm would take a PR adding the new functions, and the existing (immutable) functions should be redefined to use the mutable variants in their implementation. |
I would recommend creating a function that can fill a mutable array that was passed as an argument, rather than returning a new mutable array. This will be more flexible. You can create one mutable array and fill different parts of it with different lists, potentially even in parallel. |
While that would be more flexible, I cannot recall any instance where I wanted to fill an existing array with elements from a list. I am also not aware of any existing library that offers such a function. However, |
It is easy to implement mutableArrayFromListN :: PrimMonad m => Int -> [a] -> m (MutableArray (PrimState m) a)
mutableArrayFromListN n xs = do
marr <- newPrimArray n
fillMutableArrayWithListListN marr 0 n xs
pure marr fillMutableArrayWithListListN :: PrimMonad m => MutableArray (PrimState m) a -> Int -> Int -> [a] -> m () While inverse is not possible.
I did provide a good use case: it would allow one to use multiple lists to fill a single array, which can be a useful feature for parallelization. Here is a more important use case. With
This is definitely not a good argument that this is not a useful function. There are plenty of useful functions that could be added to |
I cannot judge the utility of this since I don't have an experience of being in such a situation.
It is not an argument that it is not a useful function, it is simply pointing out that existing libraries seem to not have acknowledged the need for such a function.
As far as I can tell, the only internal usage of Anyway, though I personally don't see the need for this, it is up to the maintainers to decide. |
FYI. I totally support adding I am also not against adding |
@andrewthad what are your thoughts? |
It would useful to have a function like
given that there already exists
My particular use case is also more directly expressed by
generate
, but I understand if this is too much for this library.The text was updated successfully, but these errors were encountered: