Itertools is a library with utility functions and data types for creating efficient iterators in Motoko.
I’ve used Motoko for a while and have created a library in the past, http-parser.mo. While creating this library, I noticed that I used Iterators a lot for looping, accumulating and mutating data for different Motoko types. I had to design custom iterators to perform most of these operations efficiently. That’s why I created this library to boost the functionality of the
Iter type in Motoko and give the developers the tools they need to build iterators without limits.
I am excited to hear your feedback about this library, and I hope it makes building your Motoko applications and canisters a little bit easier.
I’ve open-sourced the library under the MIT license, so if you have any feature requests, feel free to create an issue or open a PR.
Here’s a demo, creating chunks with a max size of 3 elements from an array
let vals = [1, 2, 3, 4, 5, 6, 7].vals();
let chunks = Itertools.chunks(vals, 3);
assert Iter.toArray(chunks) == [[1, 2, 3], [4, 5, 6], ];
This looks very nice indeed and extending Iter.mo has been on my wish-list for a while. Thank you for doing this!
I’m glad I could contribute and take a bit of your planned workload. I’ve used your
mo-pasec library in the past and have to say it was a good experience that helped me learn more about Motoko.
I tried to write docs for the use cases and limitations of all the methods in the library, so your feedback is greatly appreciated.
I unfortunately won’t have time to take a closer look in the next two days because of the supernova event, but perhaps someone else will.
Again, thank you!
Wonderful work! Thank you!
I wonder, what is the ideal path in your mind for the future? Is it one where some or all of this merges into
base, or one where it continues to evolve side-by-side, like in the Python and Rust instances?
(Or something in between those two extremes?)
I’d love to see some things make their way into base. The http parser should be considered also since http_request is a system level thing and the base type it implements is lacking.
It would be amazing if these features are merged into the base lib. However, I doubt every function will make it into the base library as I also have more planned. I think the best approach would be to deprecate methods chosen to be merged into the base library and redirect devs there. So, devs who want general iterator tools merged in the base can find them there, and those who want additional functionality can import this lib.