You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi there, enjoying using lua-stdlib but I've found the documentation for the functional routines a little sparse. Here are some suggestions for the extra detail I needed; I would be interested in your thoughts.
filter
My understanding is: if the iterator returns one value at a time (like std.elems), a sequence of the values is returned. If it returns more than one (like pairs), the first is used as the table index and the second as the value. I think this should be specified. Or at least, a general description of how the results table is indexed.
Similarly, map should mention the results table is built based on the number of returned values from the map function.
foldl and foldr should specify they operate on sequences.
Sorry for the delay! I think your suggestions make perfect sense in terms of how the functions currently work.
I'm not sure that it's the best API though... I wonder whether operating on sequences should be as fast and simple as possible, and when you want to operate on pairs in a table there is a differently named function optimized for that use case.
Can you think of a good reason to have one call that handles both cases by checking the iterator return arity, and in the worst case starting off handling a sequence (with consecutive integer key values) and changing it's mind about what to return if a non-sequential integer key arrives and all the list packing and unpacking that it then wastes time and space on?
Activity
gvvaughan commentedon Jan 5, 2022
Sorry for the delay! I think your suggestions make perfect sense in terms of how the functions currently work.
I'm not sure that it's the best API though... I wonder whether operating on sequences should be as fast and simple as possible, and when you want to operate on pairs in a table there is a differently named function optimized for that use case.
Can you think of a good reason to have one call that handles both cases by checking the iterator return arity, and in the worst case starting off handling a sequence (with consecutive integer key values) and changing it's mind about what to return if a non-sequential integer key arrives and all the list packing and unpacking that it then wastes time and space on?