Inconsistency with index-receiving `...i` methods in array, list stdlib

[alex-snezhko]

Currently, there are a few functions in the array and list modules such as map, filter, and reduce that have equivalent functions receiving an index as well as the element in the function: mapi, filteri and reducei. However, the others functions in these modules do not have such index-receiving ...i equivalents even though knowing each element's index may be useful to them. As I see it, there are 2 possible solutions to this inconsistency:

• Remove all such ...i functions and provide a different interface for such functionality, such as an enumerate function like in Python that returns tuples of (index, element)
• Add ...i equivalents to each function that iterates over elements

Personally, I prefer the first solution as it will generally de-clutter these modules and prevent from having to re-implement new functions twice. Thoughts on this?

[ospencer]

We've talked about this and actually really like the idea of an enumerate function, but it'd be fairly inefficient without generators. That did, however, get us thinking about generators in Grain 👀

[alex-snezhko]

Generators sound like a good idea. Once they get added to the language then would that also pave the way for a lazy-eval collection type like a "stream"?

Should the enumerate function be pushed off until generators are added then?

[ospencer]

Yeah, definitely. I think the enumerate function should probably wait, yeah. (I wanted to do some experimenting with generators, but there's some docs I need to get written so it might take some time before I come back around to it!)

In the meantime though, I do think it would make sense to add ...i functions where it makes sense. @phated what do you think?

[phated]

I'm on the fence on whether we should implement them. On one hand, I like consistency in the stdlib, but on the other, that is a lot of functions to deprecate (and then remove) once we have enumerate 🤔

[ospencer]

Very true. I think that the only really important ...i functions are forEach and map (maybe also reduce) so it's probably fine to just make sure we've got those and then revisit later.