Comments on the straw man...

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 modiﬁed within the body of a lambda expression, although it must be deﬁnitely 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