Use of findall for aggregate_all

Related topics popped up a couple of times in a couple of days so I need to ask:

Reading the implementation of aggregate_all/3, it seems to me that if we use one of the predefined templates (count, sum, min, max) there is actually no findall anywhere; there is no list; and so those work in “constant memory” (whatever that means, of course). Is that right?

The reason I am asking is that the docs are in a way underselling aggregate_all/3; reading the docs:

Aggregate bindings in Goal according to Template. The aggregate_all/3 version performs findall/3 on Goal.

One could assume that the findall/3 will be performed and there will be a list containing all solutions; but in fact, with the predefined templates, this does not happen. Isn’t that a main selling point of aggregate_all/3?

Thanks. Made this explicit in the docs.

I don’t know. For these type of high level operations it is typically a good idea to use the library. This is often more compact, expresses in a clearer way your intend and may exploit low-level tricks to get things done faster. In this case, using aggregate is certainly cleaner than using the non-portable and dangerous nb_setarg/3 alternative directly in your code.

And, of course, if you found a better implementation than the library, make a PR to improve the library :slight_smile: That is also how these constant-space optimizations got there.

1 Like