stack-bound vs. travelling closures proposal.

[Reinier Zwitserloot]

Who are you talking to, exactly? I haven't been modifying anything in any
mercurial repository. yet. But I don't see what the ease (or lack thereof)
of implementing stack-bound in the current nightly has to do with the merits
(or lack thereof) of either stack-bound or strawman's ET proposal.

My primary concern with strawman's exception transparency system *ISNT* the
specific syntax that's on the table today. Rather, I don't see how *ANY*
amount of tweaking to the syntax is going to lead to something that's going
to (A) avoid the need to deprecate most SAMs, and (B) ugliness, by way of
boilerplate (I think we can all agree repeating "throws E" three times in a
single method signature is boilerplate).

Stack-bound is also quite specifically _NOT_ related to inference. The only
inference of note occurring in it, is inferencing that the author of a
closure is attempting to handle checked exceptions thrown inside of his
closures in a handler outside of it, which only makes sense if said closure
is stack-bound. It will therefore infer that you meant for that closure to
in fact be stack-bound, and emit compiler errors if you do something with
that closure which makes it no longer stack-bound. What it will not do,
however, is type inference, which is what I presume you meant with
"inference" (as that's usually what that term is used for). That's because
"stack-bound" isn't a type property. It's a runtime property, along with an
internal annotation used by the compiler to emit errors, analogous to how
the assignment state of a variable is tracked internally by the compiler
(not via the type system and not runtime-introspectable), so that it can
emit "This variable may not have been assigned before you read from it"
errors.

In case I didn't make myself clear, I love generics. I also believe most
generics naysayers simply do not understand that things like
co/contravariance are intrinsically difficult. No amount of syntax sugar is
going to get rid of the concept, and the concept is inherently hard to
understand. Nevertheless we must accept that due to the complexity of
generics (as unavoidable as it might be), loads of java programmers do not
understand them in depth enough to use them to write their own libraries.
Nevertheless your average java joe likes generics because they still get to
USE them, and it's not like it's impossible to write utility libraries
without them. I was trying to draw the analogy to Exception Transparency:
Given nice libraries for fork/join, PA, (parallelizing) filter and map
operations and such, Java Joe can use these tools and just have them work,
in most cases without requiring many changes to their code, without fully
understanding how ET works. This is of course not as good a result as Java
Joe understanding them in depth, but we may have to settle for it, just like
we did with generics. I was trying to point out that neither stack-bound nor
strawman seems to be the kind of proposal where Java Joe easily understands
how to write their own parallelizing library function, though at least with
stack-bound, Java Joe *CAN* write a sequential function easily, while he
can't do so with strawman. Also, unlike strawman, stack-bound allows a much
larger chunk of existing SAM classes to support ET, which means there's a
lot less code to rewrite for Java Joe, and a lot less new ground to learn.

--Reinier Zwitserloot



On Fri, Jun 18, 2010 at 3:55 AM, Jesse Kuhnert <jkuhnert at gmail.com> wrote:

> It seems to me that even though some of the syntax being paraded
> around could be better, it is a wholly separate problem than the core
> goal of this project.
>
> The ease with which you can modify things in mercurial to come to your
> desired results might speak more to the careful thought and purity
> maintained in the language rather than how easy the temporary solution
> may seem. I only say this because I've fallen in to the same trap
> before only to curse my newbie ways later on when I realized what I
> had done. I had some kind mentors and good code to read from people
> like Howard Lewis-Ship, but I don't think the language is any place to
> allow people to make their own mistakes.
>
> More or less I think people agree with you that some form of inference
> would be nice, but it needs to be done broadly and elegantly or else
> things will start to fall apart. Much like the quarantined sections of
> my current codebase written in scala. Nice in theory but just give me
> closures and I can do away with all of it.
>
> Also don't agree with all the naysaying with generics. Yes of course I
> had more than a few puzzling moments adding support for them to my
> ognl jit extension and whatnot but overall it has been a tremendous
> blessing. Countless lines of code saved for anyone that hates
> repeating themselves - thank you for that.
>
> Let's continue to attack each problem wholly and one at a time and fit
> closures in to the language the only current elegant ways that we can.
>
> On Thursday, June 17, 2010, 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. 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.
> >>
> >
> >
>