Thanks for this additional context, Brendan. The block lambda revival was 
particularly interesting to read up on. I understand why we went down the arrow 
function path, but it’s fun to think about what ES6+ might look like had we 
taken that different path.

I’d like to keep this proposal scoped specifically to reduce because I believe 
we already have adequate tools for the early exit of generic iteration with 
“for of / break/return", or at the very least, “forEach / throw”. Reduce is 
special member of the higher order functions in that most of the others list 
higher order functions can be implemented in terms of it, which is why they’re 
sometimes called “folds” or “reducers”.

Examples include

function map(fn, array) {
  return array.reduce((a, v) => a.concat([fn(v)]), []);
}

function filter(fn, array) {
  return array.reduce((a, v) => fn(v) ? a.concat([v]) : a, []);
}

However there are a bunch of higher order functions which can’t be implemented 
in terms of reduce without the ability to early exit: “takeN”, “takeWhile”, 
“takeUntil” are a few good examples of this case.

Could you implement these functions without reduce? Of course you can. But it 
would be nice to be able to leverage the reduce function for this purpose, 
especially when using JavaScript in a pure functional way.

A bit beyond the point of the proposal, but perhaps relevant is that @@reduced 
could be useful in user-land code as well. Example: Transducers is a newer 
concept that has a couple user-land libraries out there (here’s one 
http://cognitect-labs.github.io/transducers-js/classes/transducers.html) which 
extends the reducers concept. There’s some minor gymnastics done there to 
return and detect “reduced” values. Having a realm-shared well known symbol to 
represent this general concept would very likely be reused in libraries like 
these.

Lee


From: Brendan Eich <bren...@mozilla.org<mailto:bren...@mozilla.org>>
Reply-To: "bren...@mozilla.org<mailto:bren...@mozilla.org>" 
<bren...@mozilla.org<mailto:bren...@mozilla.org>>
Date: Monday, February 23, 2015 at 2:09 PM
To: "Mark S. Miller" <erig...@google.com<mailto:erig...@google.com>>
Cc: "es-discuss@mozilla.org<mailto:es-discuss@mozilla.org>" 
<es-discuss@mozilla.org<mailto: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 
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.

Just in case anyone wants my historical two cents, I don't think this is true. 
I championed both

http://wiki.ecmascript.org/doku.php?id=strawman:block_lambda_revival

and

http://wiki.ecmascript.org/doku.php?id=strawman:arrow_function_syntax

starting well after (spring 2011) the modern (Prototype.js, 2005?) higher-order 
function revival in JS.

Anyway, however much more momentum there is today compared to four years ago, 
we still don't have a clear winner. But we've been over this ground. I dug up 
some more links in a few minutes of site: googling.

Dave Herman proposed return to label here:

http://wiki.ecmascript.org/doku.php?id=strawman:return_to_label

This led to (among others):

https://esdiscuss.org/topic/march-24-meeting-notes#content-13

where Andreas Rossberg proposed `return from` to address the problem cited in 
this thread's o.p. His example used forEach, but no matter:


  function f(o) {
    o.forEach(function g(x) {
       if (...) return 0 from f;
       let x2 = x.map(function h(y) {
         if (...) return from g
         return y*2  // returns from h
       })
       ...
    })
    return 27
  }


/be
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Reply via email to