On Thu, Mar 26, 2015 at 8:22 PM, Kyle Simpson get...@gmail.com wrote:
outer = outer.filter(function filterer(inner){
return inner.reduce(function reducer(prev,current){
if (prev === false || prev === current) return false;
return current;
});
});
I think you could write that
I think you could write that like this:
outer = outer.filter(arr =
!arr.some((e, i) =
i 0 arr[i-1] === e));
Yes, you are of course correct. What I was doing in the originally cited code
was illustrating using how `reduce(..)` by its nature supports the adjacency
check,
Um, that's not exactly what reduction is meant for.
There's lots of different ways `reduce(..)` gets used in the wild; I can list
several entirely distinct but common idioms right off the top of my head. Just
because it's not the original intent doesn't mean it's invalid to do so.
To the
Kyle Simpson schrieb:
Since `reduce(..)` conveniently can compare two adjacent elements if you always
return the current value, I decided to model the inner check as a `reduce(..)`
that reduces from the original array value to either a `false` or a truthy
value (the last element of the inner
The example code isn't very compelling either; something more real-world
would be good
I recently ran across a usage of `reduce(..)` that could have benefitted from
an early return. Figured I'd just drop it here for posterity sake, in case
anything ever comes of this idea.
I had an array of
erig...@google.commailto:erig...@google.com
Cc: es-discuss@mozilla.orgmailto:es-discuss@mozilla.org
es-discuss@mozilla.orgmailto:es-discuss@mozilla.org
Subject: Re: short-circuiting Array.prototype.reduce
Mark S. Miller wrote:
My other suspicion: The previous failure of this proposal was before many
We still an an option open to us, that would merely compatibly remove a
restriction from the language rather than add a feature: Allow labels to
remain visible across function boundaries, or at least across arrow
function boundaries. Then one could break-to-label to a label of a
lexically
On Feb 23, 2015, at 7:22 AM, Mark S. Miller wrote:
We still an an option open to us, that would merely compatibly remove a
restriction from the language rather than add a feature: Allow labels to
remain visible across function boundaries, or at least across arrow function
boundaries. Then
On Mon, Feb 23, 2015 at 10:09 AM, Andreas Rossberg rossb...@google.com
wrote:
On 23 February 2015 at 16:22, Mark S. Miller erig...@google.com wrote:
We still an an option open to us, that would merely compatibly remove a
restriction from the language rather than add a feature: Allow labels to
Mark S. Miller wrote:
My other suspicion: The previous failure of this proposal was before
many people had much hands on experience using higher order functions
in JS as a normal alternative to control structures. Now that we all
have, the need for a non-local escape may be more visceral.
On 23 February 2015 at 16:22, Mark S. Miller erig...@google.com wrote:
We still an an option open to us, that would merely compatibly remove a
restriction from the language rather than add a feature: Allow labels to
remain visible across function boundaries, or at least across arrow
function
My initial feedback is that this needs a lot more why in comparison to the
how. The only inkling of why this might be useful is an unsourced assertion
that it's done in Clojure, for unknown reasons. The example code isn't very
compelling either; something more real-world would be good there.
On Sun, Feb 22, 2015 at 10:11 PM, Domenic Denicola d...@domenic.me wrote:
My initial feedback is that this needs a lot more why in comparison to
the how.
The technical reason for this I guess, is that JS doesn't have TCP blocks,
that would allow you to stop iteration, and exit the `reduce`
13 matches
Mail list logo
