stack-bound vs. travelling closures proposal.

Reinier Zwitserloot reinier at zwitserloot.com
Fri Jun 18 10:11:12 PDT 2010


I'm not sure why you generalized to "If you can't write your own HOF without
becoming a bit of a second class citizen, then something is wrong".

In very rare cases, writing a HOF with stack-bound is slightly more
complicated than with strawman. I don't see why this requires "second
citizen" hyperbole. The rare case is specifically:

You'd like to write a HOF that parallelizes, BUT, you cannot use any of the
existing parallelizing libraries such as fork/join and roll your own, AND
you'd like to support incoming stack-bound closures.

That's the only case where you have to employ unshackle and sneakyThrow to
relay ET back to the caller thread.

Yes, it is true that strawman handles this particular extremely rare case
better than stack-bound does. But this is no different from being forced to
use an "instanceof", or a null-check, in a case where in other languages you
may have been able to handle the situation with a static instead of a
runtime check. This doesn't make you a second class citizen. We don't call
folks using a null check a "second class citizen" because in a more
extensive type system, nullity might have been expressed as a static type.
It seems strange to use that kind of hyperbole here. I fully agree that the
language should reduce situations where a runtime check is needed but a
static check could have been possible as much as possible, _but_, not at
*any* cost. The cost is too high, and the use cases are far too rare.

--Reinier Zwitserloot



On Fri, Jun 18, 2010 at 3:24 PM, Nathan Bryant
<nathan.bryant at linkshare.com>wrote:

>
>
> Reinier wrote:
>
> > Using concurrency is not the problem. It's writing the libraries. I'm
>
> You keep reiterating this point, that once the libraries have been
> written, people won't need to write any more. I don't agree. I've
> already been forced to write a custom (basically package renamed with a
> few tweaks) version of one of the nascent frameworks out there, because
> it just didn't /quite/ do what I needed.
>
> More generally, if you can't write your own HOF (whether for
> parallelization, or simple pattern encapsulation, or any other reason)
> without becoming a bit of a second class citizen, then something is
> wrong.
>


More information about the lambda-dev mailing list