feat: Document arrays and loops#341
Conversation
✅ Deploy preview ready! 🌾
To edit notification comments on pull requests, go to your Netlify site settings. |
| - efficient at adding additional elements | ||
| - efficient at removing elements | ||
| - easy to work with | ||
| - less succeptible to bugs |
There was a problem hiding this comment.
No possible IndexOutOfBounds, typically pattern matching on them which forces you to handle empty cases, etc. I was fine letting the guide have this as "take our word for it" but we could expand on that if we wanted. Wouldn't do it inline though.
There was a problem hiding this comment.
Hm, expanding might be valuable because "take our word for it" seems like a bad position for our "guide" 😛
|
|
||
| Lists and arrays are similar constructs, but each has its own pros and cons. It's up to you to choose which is right for your use case! | ||
|
|
||
| Lists are excellent because they're |
There was a problem hiding this comment.
| Lists are excellent because they're | |
| Lists are excellent at |
There was a problem hiding this comment.
I thinkthere was a better transition here because, it goes on to list the properties rather than use cases. at indicates listing specific examples. It might make sense to say something like
Lists are useful over arrays because they are immutable,
and their data structure makes resizing them more efficient,
they are easier to work with in grain and less susceptible to bugs
because it is a lot harder to get runtime errors. The downfalls of lists compared
to arrays are that they are unable to modified in place, and their data structure
makes accessing specific elements and determining the length less efficient.
Lists are best used when the size does not matter and you are constantly
appending or removing elements.
The downfall of that sentence structure is you lose the nice list though a better option over a list might be having the two paragraphs with their differences and then using a table to compare the features.
| - inefficient at accessing random elements | ||
| - inefficient at determining the number of elements | ||
|
|
||
| Arrays are excellent because they're |
There was a problem hiding this comment.
| Arrays are excellent because they're | |
| Arrays are excellent at |
There was a problem hiding this comment.
I guess the list would have to be reworded if these are both changed to "at" but I think it's best to say what they are "excellent at"
|
|
||
| - inefficient at adding additonal elements | ||
| - inefficient at removing elements | ||
| - more succeptible to bugs |
Co-authored-by: Blaine Bublitz <blaine.bublitz@gmail.com>
|
All read very well to me! |
phated
left a comment
phated
left a comment
There was a problem hiding this comment.
Still some of my inline comments to address. Sorry for not batching as a review.
| - inefficient at removing elements | ||
| - more succeptible to bugs | ||
|
|
||
| As a rule of thumb, lists are the idiomatic choice in Grain! Lean towards using lists whenever possible and use arrays when it makes your code easier to understand. |
There was a problem hiding this comment.
You might want to state that Lists are more idiomatic because they are generally easier to work with and more feature rich supporting destructuring in pattern matches and the fact that they are less likely to throw runtime errors. you might also want to note that as grain is functional lists are the better choice because you they are immutable.
There was a problem hiding this comment.
| As a rule of thumb, lists are the idiomatic choice in Grain! Lean towards using lists whenever possible and use arrays when it makes your code easier to understand. | |
| As a rule of thumb, if you have to keep track of the amount of elements or want to index to retrieve an element often, arrays are the best choice. However, you should use lists in (tail) recursive applications! Lean towards using idiomatic lists whenever possible and use arrays if you need length or random access. |
This rule of thumb more accurately paints the picture of determining the most efficient data structure for the use case.
|
This also probably closes #244 |
|
|
||
| - inefficient at adding additonal elements | ||
| - inefficient at removing elements | ||
| - more succeptible to bugs |
There was a problem hiding this comment.
| - more succeptible to bugs | |
| - more susceptible to bugs |
5 participants
Closes #339