Comments on the straw man...

[Neal Gafter]

These are thoughts that occur to me on first reading of Mark's strawman.

1. Lambda expressions.  It appears there are two forms (which I call
expression lambdas and statement lambdas).  I think that's a good idea.  It
isn't clear if the parens in the expression lambdas are a required part of
the syntax, or just happen to appear in all the examples.  A grammar to
accompany the proposal would clarify this.  I don't have strong feelings
either way, but I believe we would come to regret requiring the parens.

The strawman doesn't say anything about it, but I believe it would be an
error to require that each evaluation of a lambda expression creates a
distinct object, as Mark suggested in a previous email.  I can explain in
detail if it isn't clear why, but for a hint note that many of the examples
of lambdas in the strawman could be statically allocated (when the lambda
isn't technically a closure).  The compiler should be free to do that,
rather than requiring the programmer to reorganize the code to place each
such lambda where it is evaluated only once.

There is too little detail to see how things fit together here.  I don't
know what the type of a lambda expression is or what the type (and definite
assignment, exception, completion, binary compatibility, runtime, etc) rules
are.  The devil is in the details.

2. Function types.  The strawman doesn't give any semantics for these, so it
is hard to evaluate.  What is the syntax for checked exceptions that might
be thrown by a function?  How do I construct a class literal with these?  Do
they obey subtype rules that are covariant on return types?  Contravariant
on argument types?  If it lacks either, it would reduce the flexibility of
the ParallelArray APIs.  One option is that these types map to interfaces,
as BGGA, in which case we know a coherent spec in this direction is
possible.  I know some people would like to see method handles investigated
as an implementation mechanism for function types, but I haven't seen any
serious attempt at specifying that.

Some language work will be required to explain how variables of function
type can be invoked.  Perhaps variables of function type are also added to
the method namespace?  It will be a bit messy; the devil is in the details.

3. Function conversion.  Again, too much is missing.  What is "appropriate
type" and "as needed"?  Is this conversion applied only to lambda
expressions (as in BGGA)?  Or does it also convert variables of "function
types" (sec 2) to "SAM types", which suggests that function types are not
interfaces?  Is this an identity conversion?  A subtype conversion?  An
assignment conversion?  An argument conversion?  A boxing conversion?  In
BGGA (and therefore FCM) it is a subtype conversion so that it can be
integrated into type inference, but perhaps the strawman author has other
ideas.  Keeping the effect on type inference in mind should help prune the
design space, but the strawman gives no hint that this has been done.

What if the abstract method is generic?

If SAMs include classes (with a single abstract method), then how is the
constructor selected, and where do its arguments come from?  Can it be an
inner class?  A local class?  Are the SAM's members in scope within the body
of the closure?  If not, what is the reason to include (abstract) classes?
Including (abstract) classes also interferes with the compiler's ability to
select the allocation time (see second paragraph under 1 above).  Overall, I
believe the issues with them and the rarity of use cases argues against
supporting (abstract) classes as SAMs.

Again, the devil is in the details; without details it is hard to see if or
how function conversions fit with the rest of the strawman.

4. Variable Capture.  Needs more refinement about what is meant by
"effectively final".  Despite the strawman's reference, the JLS DA/DU rules
can't be used for this purpose; a new and separate dataflow specification
would be required.  That is likely to be comparable in size to the existing
JLS3 DA/DU analysis and require a significant effort to specify and
implement correctly.  One simple approach is to define as "effectvely final"
variables that are never subject to an assignment (initialization in the
declaration is not assignment), as the BGGA prototype does.  That is trivial
to specify.  What appears to be intended here isn't (... devil ... details).

The strawman says that "A shared variable can be modified within the body of
a lambda expression, although it must be definitely assigned-to before the
lambda expression is evaluated."  This is an error; there is no reason to
require a variable be definitely assigned if it is only written by the
lambda.

5. Scoping.  I presume all names (except lambda parameters) and
accessibility are resolved as in the lexically enclosing scope (i.e. no
names inherited from the SAM).  But this is far from clear (especially when
used with abstract class SAMs).

6. Exception transparency ala BGGA requires the type "Nothing" to be used as
an exception parameter and also in the return type for conversion of a
lambda whose body cannot complete normally, but there is no mention of
"Nothing" in the strawman.  BGGA also introduces disjunctive types and
related rules for type inference.  BGGA relies on function types being
interfaces, but the strawman explicitly leaves that open, making me wonder
what the strawman author has in mind.  There is not enough information to
even guess what is envisioned here.

If disjunctive exception types are supported, then the coin specification
for multicatch can be simplified.  It would allow the removal of the "final"
requirement on disjunctive catch parameters.

8. Extension methods.  I think more experience with alternatives would be
valuable.  My primary concern with extension methods in this form is that it
undermines one of their most valuable traits - the ability to retrofit
functionality on APIs without requiring access to the source.  That is
useful among other reasons to enable much more flexibility in future
language changes.

As a separate matter, extension methods could be used as a basis for a much
cleaner specification of array-index syntax for lists/maps.

It isn't clear if discussion of extension methods is appropriate here or in
Coin.

0. Overall impression.

Overall, my impression is that this strawman sets a stake in the ground
about how the language features might fit together without actually working
it out or verifying that the ideas are mutually compatible.  It appears to
address the simplest use cases only.  There is not enough detail to evaluate
most of it.  A great deal of work will be required to turn the ideas into a
coherent language specification, and that will likely require a significant
revision of the initial ideas.  Many of my questions would be answered in
the effort; it isn't clear what purpose was served by publishing the
strawman.

Given the amount of language design work remaining and the short time frame
(5-6 months to feature complete), does Sun plan to devote someone (or a
team) with the appropriate skills (or who have the time to develop those
skills) to the task?  When can we expect the blanks in the strawman to be
filled in?  What resources and schedule are envisioned for the
implementation/prototype?

It would be nice to have a wiki to track progress.  I can easily imagine
points being lost in discussion threads that branch from a message such as
this one.  I've provided hosting here: <http://www.javac.info/lambda/>, but
I can easily imagine Sun could provide its own hosting facilities.  (I've
sent Mark the admin password separately).

Cheers,
Neal