Delurking comments on the 0.1.5 specification

[Paul Benedict]

Since Alex said the Java 7 EG and this mailing list may or may not
have any relationship, I have begun to perceive a duality here.
I think Sun/Oracle is supporting community involvement to see if any
good ideas flesh out. So from one perspective, they are merely
observers to gather the good ideas that might exist from outside the
company. Average Joe is probably happy he can participate in a
discussion and get personal feedback from Sun/Oracle engineers. What I
don't think Average Joe knew is how little obligation Sun/Oracle has
on taking the ideas. I got the impression these mailing lists were
more than community discussion and were actually going to craft a
proposal to send to the EG. After what Alex said, it almost sounds
like everyone here is wasting their time. Why continue contributing?
It's been stated your emails may never even be read by the EG. I think
that's truly disappointing.


On Fri, Apr 2, 2010 at 12:08 PM, Serge Boulay <serge.boulay at gmail.com> wrote:
> I’m a little confused; Does this mean closures are targeted for sun/oracle
> jdk7 or just open jdk7?  What happens if a jsr group is formed and what they
> come up with is not what’s already been put into open jdk7/sun/oracle jdk7?
>
> On Fri, Apr 2, 2010 at 11:44 AM, Neal Gafter <neal at gafter.com> wrote:
>
>> On Thu, Apr 1, 2010 at 9:30 PM, Jim Mayer <jim at pentastich.org> wrote:
>> > If I've got that right, I think I'd rather enjoy the resulting
>> > programming language.  A fair number of my "top ten" bugs probably
>> > wouldn't have happened if Java had a mechanism like that.
>> >
>> > Unfortunately, I don't know how to get to a closure mechanism that
>> > supports full transparency from Java as it exists today.  I don't mean
>> > technically, because I think you've demonstrated pretty convincingly
>> > that it can be done.  I think there are issues of cultural change, of
>> > expectations, of business models, and of application spaces.
>>
>> Isn't it always someone else's fault that we don't try to do what we
>> feel is the right thing?
>>
>> > In the
>> > end, the best bet may be to try to make sure that nothing gets added
>> > to the byte codes or JVM that would make a language that DID support
>> > all of this impossible or horribly inefficient.
>>
>> And, we can make sure nothing gets added to Java that makes it
>> difficult to support transparency in Java in the future.
>>
>> > <geek-mode>
>> >
>> > If "E" is a Java expression (not statement), then, assuming that we
>> > changed the way the proposal handle's 'this', aren't the following all
>> > equivalent?
>> >
>> >    E
>> >    #(){return E;}
>> >    #(){return #(){return E;};}
>> >
>> > I think this follows from the fact that expressions can't contain
>> > 'break', 'continue', or 'return' except insofar as they show up in a
>> > lambda expression (which acts like a function body).
>> >
>> > </geek-mode>
>>
>> Yes, they are equivalent (presuming you meant to invoke the resulting
>> lambda at each step).  However, that's not transparency.  Transparency
>> is a property of the language, not a property of particular programs.
>> If your question was about the possibility of defining the lambda
>> syntax so that the return and semicolon surrounding the result
>> expression are part of the lambda syntax and not a statement, then yes
>> such a lambda syntax could be transparent but would look confusingly
>> similar to a return statement (programmers would wonder why it can't
>> be surrounded by an if statement).  Moreover, it isn't a good idea to
>> restrict the future evolution of the language by designing features
>> that assume expressions do not contain statements.  See
>> <http://www.javac.info/closures-v06a.html> for one way to add lambdas
>> now (in the spirit of project lambda) that admits a future extension
>> to full transparency, and <http://www.javac.info/closures-v06b.html>
>> for how to extend it to complete transparency in the future.  This
>> particular hypothetical future evolution does add statements that are
>> nested within expressions.
>>
>> >> Having a separate syntax for self-invocation doesn't solve the
>> >> problems that prevent recursive lambdas when "this" is defined as
>> >> referring to the innermost lambda expression.  Since the result type
>> >> is not explicit, recursive invocations in a return statement (or in an
>> >> expression lambda) would still have to be forbidden.
>> >
>> > You're right, though I wonder what the root cause of the problem is.
>> > Does anyone have a pointer to the analysis?
>> >
>> > In the factorial example
>> >
>> >    #(int n)(n == 0? 1 : n * #this(n-1))
>> >
>> > It seems that something like the logic used to determine the type of a
>> > conditional expression ought to be applicable.
>>
>> What is the type of the third operand of the conditional operator?  Is
>> it long (because the type of the lambda' result is long)?  Is it
>> double (because the type of the lambda's result is double)?  Or
>> perhaps it is int?
>>
>> Cheers,
>> Neal
>>
>>
>
>