d at domenic.me (2015-03-06T00:50:34.937Z)
On Mon, Feb 23, 2015 at 10:09 AM, Andreas Rossberg <rossberg at google.com> wrote:
> I don't see the relation to the OP's problem.
It tends to break traversing by returning a special marker. The same issue
exists e.g. with `forEach` method, not only `reduce`. The `reduce` seemed
to me just a particular case, that's why I mentioned TCP, that could solve
both.
If there are actual limitations with current state of the spec (and
complexities of implementations), it can be just that `@@reduced`. Though
then again you'd have the case like:
```javascript
$stopTraversal = {};
try {
bigData.forEach((v) => {
if (v > 100) {
$stopTraversal._returnValue = v;
throw $stopTraversal;
}
});
} catch (ex) {
if (ex === $stopTraversal) {
_data = $stopTraversal._returnValue;
}
}
```
If this is something more convenient than:
```javascript
bigData.forEach((v) { // note, it's not an arrow, but TCP block
if (v > 100) {
_data = v;
return; // could be `exit`;
}
});
```
For the `reduce` method it could actually `return '99+'`. That's said, if
the practical need exists specifically for the `reduce` function, I'm not
against having "stop traversal" mechanism only there.
On Mon, Feb 23, 2015 at 10:09 AM, Andreas Rossberg <rossberg at google.com> wrote: > On 23 February 2015 at 16:22, Mark S. Miller <erights at 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 boundaries. Then one could break-to-label to a label of a >> lexically enclosing function. >> >> This has repeatedly died in committee before because it does raise >> another case for implementors: Once the execution context of that label has >> completed, an attempt to break to that label must instead throw an error. >> I've never understood why this extra case was a show stopper. >> > > I opposed it (and still firmly do) not just because this has considerable > implementation complexity (each call could then have an arbitrary and > unknown number of exit points, not just two, and I don't even want to > imagine what that would do to our control graph) -- that is just a > consequence of the real problem, which is that this is an unstructured form > of non-local control transfer, a half-way, half-broken form of > continuations. If you want continuations, add real continuations. > > > On Sun, Feb 22, 2015 at 11:36 PM, Dmitry Soshnikov < >> dmitry.soshnikov at gmail.com> wrote: >> >>> 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` >>> context right from the callback context. With TCP it would be a `return` >>> statement, which in JS we have to solve throwing a special "marker" >>> exception, which should be caught and analyzed. >>> >> > I don't see the relation to the OP's problem. > It tends to break traversing by returning a special marker. The same issue exists e.g. with `forEach` method, not only `reduce`. The `reduce` seemed to me just a particular case, that's why I mentioned TCP, that could solve both. If there are actual limitations with current state of the spec (and complexities of implementations), it can be just that `@@reduced`. Though then again you'd have the case like: ```javascript $stopTraversal = {}; try { bigData.forEach((v) => { if (v > 100) { $stopTraversal._returnValue = v; throw $stopTraversal; } }); } catch (ex) { if (ex === $stopTraversal) { _data = $stopTraversal._returnValue; } } ``` If this is something more convenient than: ```javascript bigData.forEach((v) { // note, it's not an arrow, but TCP block if (v > 100) { _data = v; return; // could be `exit`; } }); ``` For the `reduce` method it could actually `return '99+'`. That's said, if the practical need exists specifically for the `reduce` function, I'm not against having "stop traversal" mechanism only there. Dmitry > A break would be a very poor device for exiting a reduce, since it doesn't > allow you to pass a result (you'd have to funnel that through assigning > some outer variable). Also, I don't see why you can't do the same with a > throw today. > > What Lee really wants is a partial reduce. I think this could be provided > easily without magic symbols by using the encoding of an Either type, like > e.g. iterators already do (though it's used here in the inverse direction). > For example, you could imagine the following signature: > > reducePartial<A, B>(f: (acc: A, val: B, key: number) => {value: A, done: > boolean}, init: A): A > > /Andreas > > > > >> >>> From the practical perspective, yeah, it would be good to see real >>> examples of how useful the feature is. Of course if we take the reason: >>> "exit from an hight-order iteration as soon as possible in a convenient >>> way", that could sound reasonable/practical. Although, to have concrete >>> examples would be good. >>> >>> However, I'd say, JS betters needs some sort of TCP blocks, which would >>> solve other similar cases (and which I'm pretty sure were discussed several >>> times couple of years ago). E.g. in Ruby that example would be much easier, >>> and that `@@reduced` would be just simple intuitive `return`. >>> >>> Dmitry >>> >>> >>> >>>> 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. >>>> ------------------------------ >>>> From: Lee Byron <leebyron at fb.com> >>>> Sent: 2015-02-23 00:58 >>>> To: es-discuss at mozilla.org >>>> Subject: short-circuiting Array.prototype.reduce >>>> >>>> Hey all, >>>> >>>> I’d like to propose an addition to ES7 to add @@reduced as a way to >>>> short-circuit from Array.prototype.reduce. >>>> >>>> I’ve written up a polyfill and explanation here: >>>> >>>> https://github.com/leebyron/ecma-reduced >>>> >>>> I would love your feedback on this. >>>> >>>> Lee >>>> >>>> _______________________________________________ >>>> es-discuss mailing list >>>> es-discuss at mozilla.org >>>> https://mail.mozilla.org/listinfo/es-discuss >>>> >>>> >>> >>> _______________________________________________ >>> es-discuss mailing list >>> es-discuss at mozilla.org >>> https://mail.mozilla.org/listinfo/es-discuss >>> >>> >> >> >> -- >> Cheers, >> --MarkM >> >> _______________________________________________ >> es-discuss mailing list >> es-discuss at mozilla.org >> https://mail.mozilla.org/listinfo/es-discuss >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20150223/4d46ff42/attachment-0001.html>