Well I was sort of guessing about your use case @Bartosz. But I can see that Peter has given you some code to work with anyway.
Just to be clear about what I'm saying people can propose anything they want to propose--good ideas come from lots of ideas. But I think a lot of us feel as if any changes made to core libraries need to be of a fundamental and pretty universally applicable nature. The fact that we can write code to answer some need doesn't mean it shouldn't be in the core libraries--but if we add something to the core libs it should be something with broad application and something of a pretty foundational quality. Of course my opinion is only important to me anyway but I don't want anyone to misunderstand my thinking. -- Onorio On Wed, Jun 22, 2016 at 4:34 PM, Bartosz Kalinowski <[email protected]> wrote: > I can perfectly understand being conservative about new features and I > don't mind if this doesn't get accepted because of that. Although your > example is a bit different. To be honest, what I tried to achieve felt like > a natural extension of Enum.uniq and when I discovered it's not possible to > do what I needed I was a bit dissapointed. Your example of this > RunLengthEncoder is not really the same case. The solution to the quiz > depends on the fact that the letters need to be one after the other and > Enum.merge which I suggest takes into account every element of the list. > > > On Wednesday, June 22, 2016 at 10:04:58 PM UTC+2, Onorio Catenacci wrote: >> >> I'm not sure what the use case is you were trying to address but this >> seems very similar to a run length encoded use case. If so, this isn't >> that hard to roll with existing code. Here: >> >> https://gist.github.com/benjamintanweihao/7ea8f15a0b6bb7cca26e >> >> So, yeah, we don't _need_ this functionality. That said, bear in mind, >> that whenever new things are added to core libraries they have to be >> supported from that point forward. So we tend to be conservative about >> what gets added to core libraries (and justifiably so). >> >> -- >> Onorio >> >> >> On Wednesday, June 22, 2016 at 3:15:27 PM UTC-4, Bartosz Kalinowski wrote: >>> >>> Hey guys, this is my first proposal so please be kind :) I don't know if >>> WE need this functionality, but I certainly needed this so I already >>> developed it. Obviously I'm not that familiar with Elixir yet so it might >>> happen that there is something very simmilar somewhere in the code, but I >>> looked and couldn't find it. >>> >>> >>> My idea is to "cleanup" lists which have duplicate values, but in a way >>> that will merge the duplicate values (not just ignore them like uniq/1 does) >>> by using given function (one of the params). Please let me know what you >>> think. >>> >>> >>> Examples: >>> >>> >>> iex> Enum.merge([1, 2, 3, 3, 2, 1], fn (x, y) -> x + y end) >>> >>> [2, 4, 6] >>> >>> >>> # This one is simmilar to `Enum.uniq/1` >>> >>> iex> Enum.merge([1, 2, 3, 3, 2, 1], fn (x, _y) -> x end) >>> >>> [1, 2, 3] >>> >>> >>> iex> Enum.merge_by([{1, :x}, {2, :y}, {1, :z}], fn (x, _) -> x >>> end, fn {x, _} -> x end) >>> >>> [{1, :x}, {2, :y}] >>> >>> >>> iex> Enum.merge_by([a: {:tea, 2}, b: {:tea, 2}, c: {:coffee, 1}], >>> fn (x, _) -> x end, fn {_, y} -> y end) >>> >>> [a: {:tea, 2}, c: {:coffee, 1}] >>> >>> >>> iex> Enum.merge_by([%{k: "a", v: 1}, %{k: "b", v: 2}, %{k: "a", v: >>> 3}, %{k: "b", v: 4}], fn(t1, t2) -> %{t1 | v: t1.v + t2.v} end, fn s -> >>> s.k end) >>> >>> [%{k: "a", v: 4}, %{k: "b", v: 6}] >>> >>> >>> Because I'm new here I already created PR on github which obviously got >>> closed immediately... :) But there is an upside to this, I already >>> implemented this functionality so you can see the examples in more >>> "human-readable" form on github ( >>> https://github.com/elixir-lang/elixir/pull/4854/files) to better >>> understand what I wanted to achieve :) >>> >>> >>> Please let me know if you think this would be useful and maybe if there >>> is no simmilar functionality already! >>> >> -- > You received this message because you are subscribed to a topic in the > Google Groups "elixir-lang-core" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/elixir-lang-core/NVT7XEMmldo/unsubscribe > . > To unsubscribe from this group and all its topics, send an email to > [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/elixir-lang-core/84b33056-1ed1-4291-be72-5900e053fccb%40googlegroups.com > <https://groups.google.com/d/msgid/elixir-lang-core/84b33056-1ed1-4291-be72-5900e053fccb%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- Onorio Catenacci http://onor.io http://www.google.com/+OnorioCatenacci -- 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/CAP%3DvNq9aWMDGoGpNZyf%2BY%2Bf2DAq90V8J6xz200ztGy57VodZmw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
