I wrote up most of a post about the potential to just have :map_reduce besides the existing :reduce to handle the fact that the existing implementation doesn’t handle map reduce operations well. To me this seems like the most straight forward step.
However I discared it because I don’t think that captures all the concerns of this proposal. One part is the lack of map reduce, but I guess the other important part is figuring out a declarative syntax for reduction operations. The things I currently don’t feel work great in the proposal in regards to the latter concern is two fold.
- One is that we assign initial values with
=.for let count = 0, …still looks a lot likecountwould just be0. Yes there’s aletin front, but to me that doesn’t feel like proper signaling. Added parenthesis add a bit more “look at me”, but also look more like a independant function/macro than a part offor. (Also the fact that we use text/a name seems to be reason for a lot of the current discussion, can we possibly not use a word?) It seems all existing places where variables are assigned, but have different semantics than=elixir uses<-or->in some shape or form.<-just is already used to denote generators infor. Maybe->works?
for {0, 0} -> {sum, count}, i <- [1, 2, 3] do
…
end
To me assigning an initial value actually reminds me a lot of assigning a default. Something like this:
for {sum, count} \\ {0, 0}, i <- [1, 2, 3] do
…
end
- The other part is the fact that while the “input” side to the
do/endblock is now more declarative we still retain the not so pretty fact of returning tuples of values because we need multiple returns for a map_reduce. It works, but doesn’t feel great. Though I’m also not sure there’s good alternatives with the current syntax elixir can parse without limiting when/how the accumulator can be manipulated.
I hardly did digging into the already discarded proposals, so I hope I didn’t reiterate.
Same here.
