stack-bound vs. travelling closures proposal.

[Reinier Zwitserloot]

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. The alternative is something like this:

    public <T, throws E> void parallelSorter(List<T> list, #int(T, T)(throws
E) comparator) throws E {
        ....
    }

But this is littered with problems as well. For starters,
java.util.Comparator must be retired. That's a major smell of the strawman
"throws E" syntactic method. There's no need to retire Comparator in the
stack-bound proposal. Secondly, the authors of ParallelSorter need to
understand exactly how to work with "throws E" which is difficult [*1], and
involves loads of boilerplate. The characters "throws E" occur three times
in the above snippet!

I'm basically trying to argue that the above really doesn't win over
unshackle/sneakyThrow in the "that looks pretty" department, stack-bound in
general is easier to understand (to date the majority of java programmers
still fundamentally cannot fathom why Enum's signature includes <E extends
Enum<E>>!) and the disadvantages of the strawman[*2] are as bad or worse
than the disadvantages of stack-bound[*3].

[*1] It's certainly nothing insurmountable, and plenty of folks are using
complicated generics today, but it remains a truism that the majority of
java programmers avoid declarative generics like the plague, and simply
don't understand them. They love their List<String> and Future<Foo>, but
don't really know why Enum's signature is officially Enum<E extends
Enum<E>>, nor why sort's signature is <T> void sort(List<T>, Comparator<?
super T>) - and not for example void sort(List<? extends T>, Comparator<T>).

[*2] strawman problem: The vast majority of SAM types need to be retired
because they can't be retrofitted with "throws E", and their replacements
contain lots of boilerplate.

[*3] stack-bound problem: See the "Future" snippet at the end of the OP
which simply cannot be done given the stack-bound proposal, but is
par-for-the-course in strawman.



--Reinier Zwitserloot



On Thu, Jun 17, 2010 at 11:20 AM, Neal Gafter <neal at gafter.com> wrote:

> On Wed, Jun 16, 2010 at 11:52 PM, Reinier Zwitserloot
> <reinier at zwitserloot.com> wrote:
> > The alternative is working with abstracted exception types, but that
> cannot
> > possibly work either. How would you even do that? "catch (T foo)" does
> not
> > seem to be possible given the concept of erasure. The only pragmatic
> thing
> > one might catch, then, is Throwable or Exception, which one can also do
> with
> > the restricted/portable proposal.
>
> Right.  The main thing one wants to do with exception transparency is
> not to catch the exception in the generic code, but to express in the
> type system that those exceptions are propogated out to the caller.
> It can be caught at a place where the type parameter takes on a
> concrete type.  That place might or might not be higher on the call
> stack of the same thread.
>
> Consider the sort() method you described.  How does one use
> concurrency in the implementation without undermining exception
> safety?  Passing the comparator to another thread requires storing it
> in a variable, and that variable has to have a type.
>