You are correct about filter working on predicates. I very quickly glanced this map().filter().map() in the filter_map docs, and assumed there was a filter() function without a predicate. But it does appear from the example that filter_map does merely remove None, and doesn’t take a predicate.
let a = ["1", "two", "NaN", "four", "5"];
let mut iter = a.iter().filter_map(|s| s.parse().ok());
assert_eq!(iter.next(), Some(1));
assert_eq!(iter.next(), Some(5));
assert_eq!(iter.next(), None);
I’m still not sure I understand your point. Is your point that nothing new should be added to the language, period? Since reduce covers the Enum operations, should we have stopped there? Everything beyond that adds some mental overhead for a beginner. If your point is to just not add anything new, fair enough, point taken. But if it’s more nuanced, then surely at some point you’ll have to judge something in a relative vacuum, right?
IMHO it’s easier to add stuff than remove from a language, and more verbose, complex, expressive syntax is, higher entry threshold for proposal as yours should be.
my point is that, if you will grow language syntax, make it more complex for relatively small wins, you will bloat it, because you will never be able to decommission and deprecate enough other, alternative syntaxes to balance the growth.
i think our reference frame to judge such additions should be broader, to see where language will go after - let’s say - 30 such additions over 2-5 years.
discussing “proposal vs reduce” is just “too confined”, in my opinion.
i don’t want to send contradictory signals, but i still think such proposals are worth discussing, and of course i am not saying language is finished and the best, and there is nothing to improve. it just doesn’t mean it will be easy to push such proposals through or that even majority of them are worth it.
i don’t believe way you are framing it is correct. overhead we are talking about is a cost for everyone, no matter how advanced or smart you are. language complexity will always impose load on you, no matter who you are.
also, who is average user of the language? genius developer? blue collar coder?
again, i am not saying nothing new should be added. please check what i wrote above.
personally, i am quite happy with tools Elixir gives me already, and to me cost of introducing changes you are proposing is much higher than perceived benefits.
just an opinion of a random guy from the internet
I’m kinda surprised no one has mentioned for comprehensions. When I think of map/flat_map with a filter, that’s where my mind goes. Of course, to some people’s taste, this may be even more golf-y than flat_map Here’s how I’d do it in one line, a single pass through the Enumerable, and no extra List.wrap:
iex(29)> for x <- [1, 2, 3, 4], y = x + 1, Integer.is_odd(y), do: y
[3, 5]
edit: I thought of a better example where we use a helper function that may return nil or not which fits more closely with the original situation
iex(30)> odd_to_nil = fn x -> if Integer.is_odd(x), do: nil, else: x end
#Function<42.105768164/1 in :erl_eval.expr/6>
iex(31)> for x <- [1, 2, 3, 4], y = odd_to_nil.(x), do: y
[2, 4]
The main piece to understand are filters in for comprehensions. If you have a clause that is not a generator, it’s a filter. If it evaluates to falsy, then the do block is not executed and the next iteration begins.
I’m generally happy with status quo but would use it if it were available. Even though it makes sense and I can’t think of anything better, there’s something about the term “compact” that I never liked for this use-case, so in a weird way I’ve enjoyed being forced to “reject nils” in so many words.
Also, there is something off about a function that has “map” in its name that doesn’t return a list of the same size that went into it. Though there are probably examples I’m not thinking of… like map_reduce, though the original length map is still in there
EDIT: I re-read the thread and had missed @dimitarvp’s message re: filter_map which I believe Elixir actually used to have? In any event, there is precedence when it comes to my differing-length concerns so I suppose it’s a moot point.
And I was wondering why I can’t quickly find filter_map… It was last directly accessible in the docs all the way back in Elixir 1.4.5, woah.
I understand the liking of the for comprehension and used it a lot but the whole truthy / falsy thing just rings my alarms as I am an other side of the spectrum and I want explicitness all the way to the point of ju-u-ust before it becomes unwieldy and annoying. To me the truthy / falsy semantics will be never welcome but oh well. Just adding one more anecdote because arguing for/against it is fruitless; it’s just a preference in the end, and it is clear that the core team is not on my side in this instance. I’ll just never ever approve of the if value ... thing.
But that’s why I guess I’m still confused by your point. You initially stated you get excited by map, but don’t like bloat. map is just reduce keeping all the elements.
personally, i am quite happy with tools Elixir gives me already
Ok, so if we look at something like sum/1. It can be implemented as simply as reduce(list, & &1 + &2). It’s also a function that only works on a list of a specific subset of types. There’s a number of functions that come in pairs like uniq/1 and uniq_by/2 where uniq/1 could easily be called as uniq_by(enum, & &1). There’s max and min, but also min_max(which of course could be achieved through min and max)
So your point is you don’t like bloat, but you like everything that’s currently in Elixir. So by what metric is sum and uniq, which have very simple implementations with reduce and uniq_by, not bloat? It seems like you define bloat as anything not currently in the language.
I’m not suggesting any of those functions are by my definition bloat, but it just seems like a confusing point to say “I don’t like bloat, everything currently in Elixir isn’t bloat, but we can’t compare anything because that’s too narrow”.
I agree with your statement that adding things for small wins will bloat the language, but I’m confused why you think min_max or sum provides value that couldn’t be achieved otherwise, but that anything else is bloat. Why is min_max(functionality already well served by min and max) more valuable than say mean/median/mode, something that’s a bit more complicated to implement with the current tools in Enum?
so, i am excited about stuff like map, reduce in general - they are pretty universal.
i am not saying map on its own is enough to solve your case, but you can add stuff like filter to your recipe and you are probably good.
reg. “I don’t like bloat, everything currently in Elixir isn’t bloat, but we can’t compare anything because that’s too narrow” - let me put that this way: what i mean is that, adding your proposal to the language won’t make it slimmer or more elegant syntactically . if there is any bloat in Elixir, i don’t think it’s map or reduce.
btw. i appreciate you iterating over the matter, trying to get to the bottom of it. thank you!
I’m now seeing the bloat argument (I’m also very against bloat and am often loud about).
I think a good metric is what José mentioned: the question is “why do you need compact so often?” Everyone once in a while we’re going to need to “compact” (which again I dislike the name even if it is understood generally) but does it really need to be codified? On the other hand, sum and uniq are common needs and with super clear and expressive names… well, uniq could be spelled properly
I also brought up the example of min_max. Is that something that is needed so often that calling {Enum.min(list), Enum.max(list)} became cumbersome? I’d say I need to remove nils from a list more often than I need min_max, and to implement min_max with the existing min and max functions is absurdly easy. Also I wasn’t suggesting there’s no need for uniq, merely that if the issue is bloat, uniq_by(list, & &1) is identical to uniq.
I’m not suggesting that anything needs to be removed from the language, but if the arguments against adding anything is bloat, it’s hard to say there’s not things in Enum already that are arguably bloat, yet they got approved.
The reason for needing compact, is because I would say there’s probably no other single value more frequently returned from an Elixir function than nil(true, and false might be the only other contenders). nil also happens to be a value that is quite often not needed when it’s in a list of other, non-nil values, hence the need to compact. Also I would agree that a compact function is likely bloat because it’s no different than reject(&is_nil/1). My proposal is only for a compact_map function that maps keeping only non-nils.
My argument for codifying it is because it more closely aligns with the way I logically think about that operation, and maybe others do too. If I’m mapping over a list of numbers, adding some value, then keeping anything greater than 5, that’s two clear logical steps in my head, a map, then a filter. But to me “for each item in the list, fetch the result of calling some function that’s not nil” is more how I think of it, than “fetch the result of the function for each item, then filter out the nils”. Surely a lot of the functions in Enum that can be implemented with other functions are there because they more closely align with how we think of something. random is probably how people think of fetching a random element, even if list |> shuffle() |> List.first() is functionally the same. Most people don’t think of a random item as being the first item of a shuffled list, they just think get a random element.
Here’s how I’d do it in one line, a single pass through the Enumerable, and no extra List.wrap:
. if there is any bloat in Elixir, i don’t think it’s