stack-bound vs. travelling closures proposal.

[Jesse Kuhnert]

Wow, those where a lot of words. I feel like you have something to
prove but have stumbled in to something over your head. Either that or
your delivery is so patronizing:big suv driver-ish that I feel
compelled to disagree with anything you say.

If you had a point in there somewhere you lost me after the first
couple sentences.

On Thursday, June 17, 2010, Reinier Zwitserloot <reinier at zwitserloot.com> wrote:
> 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
>>>
>