David Herman wrote:
We've given this quite a bit of time, and I don't know how far we're going to
get in understanding all the details of your proposal. But I think I can
address some of my disagreements.
1) I'm skeptical whether the requirement you stated of future-proofing code for
async implementations is likely to happen, and in fact, I think it would be
harmful. Take your example: someone writes an Arrayish API, and maybe it's
concurrent, maybe it's not, maybe it changes to become concurrent at some
point. So a client writes:
...
function push3() {
arrayish.push->(3);
}
Whoever uses push3 now has to be aware that it may or may not happen
concurrently, so they have to be concurrency-safe too. Otherwise they might be
tempted to do:
push3();
var x = arrayish.pop(); // this is gonna be 3, I'm sure of it!
and sadness would ensue. You're proposing making it easier to create mutable
concurrent (or possibly-concurrent) data structures. Greasing the wheels of
shared-state concurrency is dangerous and not a good idea for ES.
Yes, a good example of how this proposal doesn't compose. Suppose push3
returned an object which the caller needed:
...
function push3() {
arrayish.push->(3);
return someComputation();
}
var r = push3();
var x = arrayish.pop(); // this is gonna be 3, I'm sure of it!
How would you get something like this to work?
2) I don't fully understand why you have so much machinery around chaining
continuations. There are two ways in which chaining happens in existing code:
nested flows through host-API callbacks (expressed in CPS), and explicit
composition. With first-class continuations, the former is already alleviated
for free-- there's no need for additional machinery to wire together pieces of
the continuation. And if you represent captured continuations as functions, you
still get composition on the cheap with good old function composition.
Ditto.
3) I'm also unsure what you mean by "preserving causality" or "preserving
stacks"
Me too.
5) We should also aim for a design that tries to be compatible with existing
API's, so that people don't have to write wrappers for all the standard
libraries. As much as possible, anyway.
Yes, that bothers me too. I'd want a simple continuation, not a continuation
that takes a continuation parameter.
6. If I understand it correctly, another issue I see is that this
transformation causes an exponential code size blowup in situations like the
following:
while (condition0) {
if (condition1) x = a->(x);
if (condition2) x = a->(x);
if (condition3) x = a->(x);
if (condition4) x = a->(x);
if (condition5) x = a->(x);
if (condition6) x = a->(x);
...
}
Waldemar
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
