Reducers

[ericmj]

No description provided.

[josevalim]

Since both this clause and the next clause are basically doing a reduction, I think we can get rid of this one altogether.

[josevalim]

This one is wrong. Basically, after the first time the function returns false, we get the rest of the list. It should be something like:

fn
  (entry, []) -> if fun.(entry), do: [], else: [entry]
  (entry, acc) -> [entry|acc]
end

We are basically using the accumulator to check if something was added so far (or not).

[ericmj]

Good catch, will add tests for it aswell.

[josevalim]

❤️ 💚 💙 💛 💜

[josevalim]

Replace nil by true here and in the next line, and we can get rid of the true return value before catch.

[josevalim]

I have seen that you kept the specific clauses for lists in many functions but we can get rid of many of them. We definitely should remove: Enum.count/2, Enum.join/2, Enum.map_join/3, Enum.partition/2, Enum.map_reduce/3, Enum.reduce/2 as the reducer clause will provide the same performance benefits.

We should also rewrite Enum.max(list), Enum.min(list) to use reducers instead of :lists.max(list) and :lists.min(list) (I want to avoid dependency on :lists which is not tail recursive).

We should consider removing the specific lists clauses for Enum.all?/2, Enum.any?/2, Enum.fetch/2, Enum.find_index/2, Enum.find/3 and Enum.find_value/3 too. The only extra overhead is a throw. But let's not worry about it now, we can always discuss those later.

[ericmj]

@josevalim New commit with discussed changes.

[josevalim]

There are two things pending I believe:

1. Should we still call the protocol Enum.Iterator? We could rename it to Enumerable, Enum.Reducible, Enum.Collection, etc
2. Docs for reduce in the protocol

/cc @alco @devinus @yrashk @ericmj please tell me your thoughts

[ericmj]

I think I prefer Enum.Reducible. I'm working on the docs.

[meh]

I'd call it Enumerable, the point of it is clearer, Enum.Reducible doesn't sound clear at all.

[ericmj]

I'd call it Enumerable, the point of it is clearer, Enum.Reducible doesn't sound clear at all.

It is simply something that is reducible with the reduce function. Although, we also supply the functions member? and count so Reducible might not be the perfect name.

[alco]

I'd like to see how the docs will describe this new stuff before deciding on the name.

[ericmj]

Added documentation

[alco]

It would be nice to have some historical background of the reasons for migrating from iterator to reduce. Not necessarily in the docs, it could be mentioned in a commit message.

Since the main point of the protocol is reducing a collection, I'd call it Enum.Reducer. A collection is called reducible if it implements Reducer, i.e. it is compatible with Enum functions.

Enumerable doesn't quite fit -- it implies enumeration of a collection. But Enum doesn't simply enumerate, it produces something new (a list) for the given collection. Therefore, Reducer is sufficiently descriptive in my view -- we'd call a reducer something that helps transform the collection by means of the reduce function.

[josevalim]

The problem with calling it reducer is that, if we add another important operation to Enum.Reducer, let's say map, should we still call it a reducer?

[meh]

Yeah, I think it makes sense to call it Enumerable because that's what it does is make it work with Enum functions, it's as general as possible, even considering most functions just use reduce, it's better to be safe and make it general than be sorry later and be stuck with a deadly breakage or unfit name.

[josevalim]

@alco I am writing a blog post about it. That will be included in the release announcement. :)