For now I'm not trying to put forward any 'concrete' implementation. It's
just an idea for a generalised function.
While I understand that there's no `Enum.filter` written explicitly in the
code, there's still this step of sort of filtering out, written one way or
the other, which at high level looks like filtering e.g. the simplest
example is this:
```
def count(enumerable, fun) do
reduce(enumerable, 0, fn entry, acc ->
if(fun.(entry), do: acc + 1, else: acc)
end)
end
```
The implementation wouldn't require new code itself, was just thinking at
applying functions already existing together
Il giorno martedì 12 gennaio 2021 alle 22:54:23 UTC+1 [email protected] ha
scritto:
> That was my implementation; I don’t want Luca’s proposal to be tainted by
> the inefficient implementation I put in to try to understand the proposal.
>
> -a
>
> On Tue, Jan 12, 2021 at 4:49 PM José Valim <[email protected]> wrote:
>
>> Hi folks, let’s please keep the tone of the discussion constructive.
>>
>> Luca, can you please outline which functions you believe would be
>> replaced by operation_by/4 and how? You mentioned count/2 and others ending
>> with _by, but the many of the latter cannot be replaced by your proposed
>> function. Functions like max_by, frequencies_by and similar are not doing
>> filtering.
>>
>> Also, the implementation you propose would be less efficient, as it by
>> definition does a separate filter pass on the data before calling another
>> Enum function.
>>
>> So if you can provide more information, that would help reframe the
>> discussion.
>>
>>
>>
>>
>> On Tue, Jan 12, 2021 at 22:27 Luca Campobasso <[email protected]> wrote:
>>
>>> Yes, but also we can do pretty much everything with recursion and
>>> if/else statements, so no need for the for-comprehension too.
>>>
>>> What I'm proposing is to get rid of all the functions in the Enum API
>>> that add an arity like the ones mentioned above.
>>> Here I see that you refuse all kinds of functions, saying that "you can
>>> just do A + B", but meanwhile the same API is littered with functions that
>>> are "A + B" too.
>>>
>>> So what I see here, with your answers, is that you draw the line on
>>> which functions to add and which not, simply on the mood you're on today.
>>>
>>> Il giorno martedì 12 gennaio 2021 alle 19:08:06 UTC+1 [email protected]
>>> ha scritto:
>>>
>>>> It seems to me that we already have something very similar to the
>>>> hypothetical `Enum.operation_by`.
>>>> Namely: for-comprehensions.
>>>>
>>>> ~Qqwy/W-M
>>>> On 12-01-2021 17:36, Luca Campobasso wrote:
>>>>
>>>> Well, the name could be everything else, I'm not too attached to it,
>>>> nor to the arguments order. Yes, I meant it to have arity 4.
>>>>
>>>> My main argument for adding something like this is that there are
>>>> already several functions like it, like count/2 (filter and count) and the
>>>> others ending by "_by", which add a lot of stuff to the core library, and
>>>> could be implemented with the example you gave me too, e.g. count/2:
>>>>
>>>> ```
>>>> list
>>>> |> Enum.reduce(0, fn value, acc ->
>>>> if fun_filter(value) do
>>>> acc + 1
>>>> else
>>>> acc
>>>> end)
>>>> ```
>>>>
>>>> So, this addition would actually *reduce* the dimension of the core
>>>> Enum library.
>>>>
>>>>
>>>>
>>>> Il giorno martedì 12 gennaio 2021 alle 17:10:43 UTC+1
>>>> [email protected] ha scritto:
>>>>
>>>>> I don’t like the name, but the idea here would be for
>>>>> `Enum.operation_by/4`, wouldn’t it, or would it be a function that
>>>>> returns
>>>>> a function?
>>>>>
>>>>> Something like:
>>>>>
>>>>> ```elixir
>>>>> def operation_by(operation, transform_fun, filter_fun)
>>>>> fn enumerable ->
>>>>> filtered = Enum.filter(enumerable, filter_fun)
>>>>> apply(Enum, operation, [filtered, transform_fun])
>>>>> end
>>>>> end
>>>>>
>>>>> def operation_by(enumerable, operation, transform_fun, filter_fun)
>>>>> filtered = Enum.filter(enumerable)
>>>>> apply(Enum, operation, [filtered, transform_fun])
>>>>> end
>>>>> ```
>>>>>
>>>>> So this would visibly replace `enum |> filter(filter_fun) |>
>>>>> map(transform_fun)` as `enum |> operation_by(:map, transform_fun,
>>>>> filter_fun)`.
>>>>>
>>>>> I’m not sure that this offers _enough_ visual benefit (and
>>>>> operation_by isn’t exactly a catchy name) that it would be worth adding
>>>>> to
>>>>> core. If it could _also_ provide a _performance_ benefit, I think it’d be
>>>>> an easier win. Especially as a filter-and-transform can be done pretty
>>>>> easily with `Enum.reduce`:
>>>>>
>>>>> ```elixir
>>>>> list
>>>>> |> Enum.reduce([], fn value, acc ->
>>>>> if Integer.mod(value, 3) == 0 do
>>>>> [ value * value | acc ]
>>>>> else
>>>>> acc
>>>>> end)
>>>>> |> Enum.reverse()
>>>>> ```
>>>>>
>>>>> -a
>>>>>
>>>>> On Tue, Jan 12, 2021 at 7:32 AM Luca Campobasso <[email protected]>
>>>>> wrote:
>>>>>
>>>>>> There are already some functions that take a filter function with the
>>>>>> operation, like `Enum.count/1` and its filtered version, or
>>>>>> `Enum.count/2`.
>>>>>> Some other functions, like `Enum.max` or `Enum.frequencies` have a `_by`
>>>>>> version that takes an additional argument.
>>>>>>
>>>>>> It would be cool and much more succinct, also for the library, if we
>>>>>> could generalise this behavior to all functions, and have a function
>>>>>> that
>>>>>> takes a function name as an atom, its "operating" function, and a filter
>>>>>> function, i.e. something like this:
>>>>>> ```
>>>>>> Enum.operation_by(:map, &String.downcase/1, &filter_fun/1)
>>>>>> ```
>>>>>> which I think would consistently reduce the dimension of the API.
>>>>>> People often use filtering before doing stuff with Enum. This doesn't
>>>>>> bring
>>>>>> any new function, but rather generalises a behaviour and reduces the
>>>>>> amount
>>>>>> of stuff one would need to remember or know about the Enum API (which by
>>>>>> the way, it's a work of art as it is TBH).
>>>>>>
>>>>>>
>>>>>>
>>>>> --
>>>>>> You received this message because you are subscribed to the Google
>>>>>> Groups "elixir-lang-core" group.
>>>>>> To unsubscribe from this group and stop receiving emails from it,
>>>>>> send an email to [email protected].
>>>>>> To view this discussion on the web visit
>>>>>> https://groups.google.com/d/msgid/elixir-lang-core/d6ae0579-04d7-4a2c-944a-f7279c789004n%40googlegroups.com
>>>>>>
>>>>>> <https://groups.google.com/d/msgid/elixir-lang-core/d6ae0579-04d7-4a2c-944a-f7279c789004n%40googlegroups.com?utm_medium=email&utm_source=footer>
>>>>>> .
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Austin Ziegler • [email protected] • [email protected]
>>>>> http://www.halostatue.ca/ • http://twitter.com/halostatue
>>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google
>>>> Groups "elixir-lang-core" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>> an email to [email protected].
>>>>
>>>> To view this discussion on the web visit
>>>> https://groups.google.com/d/msgid/elixir-lang-core/e9c86716-82f5-4e44-9c75-799421de8836n%40googlegroups.com
>>>>
>>>> <https://groups.google.com/d/msgid/elixir-lang-core/e9c86716-82f5-4e44-9c75-799421de8836n%40googlegroups.com?utm_medium=email&utm_source=footer>
>>>> .
>>>>
>>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "elixir-lang-core" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to [email protected].
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/elixir-lang-core/dc587460-294e-484c-a8d9-42ba3a77cedan%40googlegroups.com
>>>
>>> <https://groups.google.com/d/msgid/elixir-lang-core/dc587460-294e-484c-a8d9-42ba3a77cedan%40googlegroups.com?utm_medium=email&utm_source=footer>
>>> .
>>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "elixir-lang-core" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to [email protected].
>>
> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4LgK1CfzoxfOo-4G6jikMQLPBOZXWWgCLxgLhY4Ek6SUg%40mail.gmail.com
>>
>> <https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4LgK1CfzoxfOo-4G6jikMQLPBOZXWWgCLxgLhY4Ek6SUg%40mail.gmail.com?utm_medium=email&utm_source=footer>
>> .
>>
>
>
> --
> Austin Ziegler • [email protected] • [email protected]
> http://www.halostatue.ca/ • http://twitter.com/halostatue
>
--
You received this message because you are subscribed to the Google Groups
"elixir-lang-core" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/elixir-lang-core/4e4ea0e3-8851-43e5-92d8-7b52b657e407n%40googlegroups.com.
