d at domenic.me (2015-03-06T00:50:02.511Z)
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. 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
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. 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/c82a7e3c/attachment-0001.html>