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.
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.
3) I'm also unsure what you mean by "preserving causality" or "preserving
stacks" -- but I thought you meant that you wanted debugging environments to be
able to present natural stack traces in the presence of continuations. Again,
this seems unproblematic to me with a traditional continuation-capture
mechanism. Assuming a semantics where -> causes a continuation capture, if you
do:
function foo(...) {
f->(...);
g->(...);
}
and the call to g throws an exception, it's perfectly easy for an
implementation to report that this came from the body of foo.
4) Your design seems to have too much window-dressing and I don't have
confidence that it's well-specified in the core parts. At least, the goto-laden
spec with implicit entry points won't cut it. I think it's fair to say, if
Waldemar can't understand your semantics, You're Doing It Wrong. ;)
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.
Dave
On Apr 6, 2010, at 6:04 AM, Kris Zyp wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
>
> On 4/5/2010 7:05 PM, Waldemar Horwat wrote:
>> David Herman wrote:
>>> Your answers keep leaving out the definition of the function
>>> that you're calling via `->', which is supposed to be the part
>>> that creates the requisite object with `continueWith' etc.
>>> Examples don't do much good if they skip the part they were
>>> supposed to illustrate!
>>
>> I have the same comments as David here. I don't understand what
>> you're trying to do here with the many levels of closures that
>> take closures that take closures that take closures that ... ad
>> infinitum. I have yet to see the case that bottoms the whole
>> thing out. The thing that makes your proposals so painful to read
>> is that the examples quickly blow up into too much code to figure
>> out your intent.
>>
>
> That is kind of the point, continuation passing style quickly becomes
> extremely complicated for non-trivial code flows. However, if my
> coding examples are poorly organized or unnecessarily complicated, I'd
> be glad to change them. Maybe it would help if you translated some
> JS1.7 code (I assume you know how JS1.7 generators work), and I could
> use that as a basis for my samples. How about:
> function foo(){
> var a = bar();
> if(yield a)
> yield hi();
> bye();
> }
>
> Once again my primary intention is that JS1.7 generators provide the
> type of continuations/coroutines support that we want, they just need
> a more generalizable API, so they can be used for more than just
> generators.
>
> - --
> Kris Zyp
> SitePen
> (503) 806-1841
> http://sitepen.com
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAku7MU4ACgkQ9VpNnHc4zAxS8ACfeg+GbXGMUgIdFlU+CpJDgoVW
> FIcAnjeF5dyWRSzpuMIbiAnlM/nweGg2
> =nplm
> -----END PGP SIGNATURE-----
>
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
