Delurking comments on the 0.1.5 specification

[Neal Gafter]

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