stack-bound vs. travelling closures proposal.

[Peter Levart]

On 06/18/10, Reinier Zwitserloot wrote:
> Using concurrency is not the problem. It's writing the libraries. I'm
> working on the theory that the number of people engaged in writing low-level
> concurrency libraries is limited. Get it right once, in other words.
> 
> strawman makes using these libraries more difficult because most SAM types
> will have to be retired to support 'throws E'. 

You're assuming that those libraries are already written and that they are already using existing SAM types and that nobody is going to adapt them to use function types. Isn't project lambda all about enabling writing those libraries? If those libraries are going to be written after (or with) JDK7, then your concern about old SAM types doesn't apply. Those libraries will use function types. Old platform libraries (ExecutorService & friends) I presume can be extended to support exeption-transparent function types in addition to be backwards compatible with old SAM types.

It would be a nice exercise to start thinking about possible ways to extend existing platform concurrent libraries to support and make use of function types.

> It also makes writing utility
> functions that don't themselves engage in concurrency (though they can of
> course use received closures as arguments to concurrent utilities) far
> harder than stack-bound; stack-bound actually gives exception transparency
> to such functions for the mere cost of adding 1 keyword to the appropriate
> parameter.

I don't think that adding one more generic parameter to the API method makes it far harder if the API method already uses 2 or more generic parameters. It is more keywords, yes, but as you say, those are "utility functions" and are written once but used multiple times.

Regards, Peter

> 
> --Reinier Zwitserloot
> 
> 
> 
> On Fri, Jun 18, 2010 at 6:42 AM, Neal Gafter <neal at gafter.com> wrote:
> 
> > On Thu, Jun 17, 2010 at 6:12 PM, Reinier Zwitserloot
> > <reinier at zwitserloot.com> wrote:
> > > Parellizing sort can be done in a similar way to the example
> > implementation
> > > of forEachParallelized.
> > > Yes, it's ugly, and involves both unshackle and sneakyThrow, but it would
> > > work just fine.
> >
> > Recall that better concurrency support is one of the motivations for
> > adding lambda.  If the language forces programmers to undermine the
> > type system (or exception checking system) in order to use
> > concurrency, then we've failed.
> >
> 
>