Skip to content
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

Ease of Use Improvements #134

Open
Simre1 opened this issue Dec 24, 2023 · 0 comments
Open

Ease of Use Improvements #134

Simre1 opened this issue Dec 24, 2023 · 0 comments

Comments

@Simre1
Copy link

Simre1 commented Dec 24, 2023

I think massiv is a great library and delivers great performance. However, I believe it is also very hard to use due to the complicated types. Here are some rather radical ideas which might improve the situation.

  1. Assume Seq everywhere which is usually the right choice. If parallel computation is desired, Par should be specified when computing.
  2. Remove function names with ' at the end. I think the partial functions should be the default ones; indexing/dimension errors are usually programming errors.
  3. Be less polymorphic. Make makeArray and other generation functions return delayed arrays to aid type inference and make it less confusing.
  4. Support OverloadedRecordDot for IxN and SzN to get the individual coordinates
  5. The doc page for Data.Massiv.Array is very long and it is often hard to find the right functions. Maybe put the M variants in a different place and have a separate docs for them (e.g. Data.Massiv.Array.Safe).
  6. Combine the safe and partial functions into one by combining Dimension n and Dim, i.e. provide a constructor for Dimension that is not checked.
  7. Replace index, read with a partial function. I would imagine that many people use them in combination with fromJust.
  8. There are potentially too many different representations. However, I am not too sure what to do here.

Please feel free to tell me what you think about these changes. Not all of them might be good but I included them to be thought-provoking.

These changes are obviously breaking changes and would need a major version update. Maybe others also have some ideas if backwards compatibility restrictions could be ignored.

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

No branches or pull requests

1 participant