Delurking comments on the 0.1.5 specification

[Serge Boulay]

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
>
>