lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

Hi Peter,

Quoting Peter Aronoff (2016-09-12 15:45:33)
> Adrián Pérez de Castro <> wrote:
> > The lua-itertools module provides a collection of functional utilities to
> > use with coroutine-based iterators. One of the main goals is to provide
> > composable functions which work well together. Parts of the API are
> > loosely based on some of the Python builtins (e.g. map, filter), and the
> > itertools [1] module.
> > 
> > So far the module includes functionality that I have needed myself. I am
> > open to add additional functions — even if it's just a suggestion,
> > contributions are appreciated :-)
> Thanks so much for sharing this. I maintain a (somewhat) similar module
> called tableutils. I mention it only because you may find it useful in
> terms of functions and ideas to consider (or to avoid!). I know I’ll be
> looking at itertools in a similar light.

Oh, somehow I didn't find your module when searching for something that would
work for my use cases. It is definitely quite neat.

> For what it’s worth, I can think of two obvious differences:
> 1. itertools is, as you say, coroutine-based; tableutils is not. I’ll have
>    to think about whether I should change this.

Though I did not mention it in the announcement post, the rationaly goes like
this in my head: coroutines are more flexible and very cheap in Lua, so why
not? It looks to me that using them allows for doing interesting things while
iterating (let's say, for example, evented I/O :P).

(Disclaimer: I have been using cqueues [1] and lua-http [2] lately.)

> 2. tableutils divides its functions between two (separately loadable)
>    files: listutils and hashutils. In practice, I find that 90% of the
>    tables I use in Lua are either list-like (i.e. sequences) or hash-like
>    (i.e. dictionaries). So it made sense for me to provide helper functions
>    for each type of table separately.

Now this is an interesting idea... Depending on how/if “itertools” grows, I
might end up doing a similar split.

Also, I am not completely convinced about yielding table with two elements
when iterating both table keys and values. Right now it does something like
“coroutine.yield({ key, value })” because that makes the iterator easier to
compose with other functions, but I have not used “itertools.items()” much in
real code for the moment, so I might revisit that decision and change it to
something like “coroutine.yield(key, value)”... That's also why the API is
small and has just the things I use: I don't want take many decisions on how
to do things without experimenting a bit writing actual code that uses the

> Anyhow, thanks again for writing and sharing itertools.

You're welcome! And thanks to you for pointing out to your module — I'll be
reading through it for inspiration :-)


 ☛ Adrián

Attachment: signature.asc
Description: signature