External References: Issues List for Closures for Java (CfJ) version 0.6 parts a and b

[Neal Gafter]

Alex Buckley asked me to include BGGA and other documents in messages on
this list, so that they may formally be considered contributions to project
lambda.

Enclosed please find the Issues Lists Closure for Java specification,
version 0.6, parts a and b.  They can also be found at <
http://www.javac.info/issues-v06a.html> and <
http://www.javac.info/issues-v06b.html>.

Closures: Open Issues (v0.6a)

   - *Can Method Handles be used for Function Types?*
   It isn't obvious how to make that work. One problem is that Method
   Handles reify type parameters, but in a way that interferes with function
   subtyping.
   - *Can we get rid of the explicit declaration of "throws" type
   parameters?*
   The idea would be to use disjuntive type inference whenever the declared
   bound is a checked exception type. This is not strictly backward compatible,
   but it's unlikely to break real existing code. We probably can't get rid of
   "throws" in the type argument, however, due to syntactic ambiguity.
   - *Disallow @Shared on old-style loop index variables*
   - *Handle interfaces like Comparator that define more than one method*,
   all but one of which will be implemented by a method inherited from
   Object.
   The definition of "interface with a single method" should count only
   methods that would not be implemented by a method in Object and should
   count multiple methods as one if implementing one of them would implement
   them all. Mainly, this requires a more precise specification of what it
   means for an interface to have only a single abstract method.
   - *Specify mapping from function types to interfaces*: names, parameters,
   etc.
   We should fully specify the mapping from function types to
   system-generated interfaces precisely.
   - *Type inference*. The rules for type inference need to be augmented to
   accomodate the inference of exception type parameters. Similarly, the
   subtype relationships used by the closure conversion should be reflected as
   well.
   - *Elided exception type parameters* to help retrofit exception
   transparency.
   Perhaps make elided exception type parameters mean the bound. This
   enables retrofitting existing generic interfaces that don't have a type
   parameter for the exception, such as java.util.concurrent.Callable, by
   adding a new generic exception parameter.
   - *How are class literals for function types formed?*
   Is it #void().class ? If so, how does it work if object types are erased?
   Is it #?(?).class ?
   - *The system class loader should dynamically generate function type
   interfaces.
   *The interfaces corresponding to function types should be generated on
   demand by the bootstrap class loader, so they can be shared among all user
   code. For the prototype, we may have javac generate these interfaces so
   prototype-generated code can run on stock (JDK5-6) VMs.
   - *Must the evaluation of a lambda expression produce a fresh object each
   time?*
   Hopefully not. If a lambda captures no variables from an enclosing scope,
   for example, it can be allocated statically. Similarly, in other situations
   a lambda could be moved out of an inner loop if it doesn't capture any
   variables declared inside the loop. It would therefore be best if the
   specification promises nothing about the reference identity of the result of
   a lambda expression, so such optimizations can be done by the compiler.

------------------------------
[image: Creative Commons
License]<http://creativecommons.org/licenses/by-sa/3.0/us/>
Closures for Java by Neal Gafter and Peter von der
Ahé<http://www.javac.info/>is licensed under a Creative
Commons Attribution-Share Alike 3.0 United States
License<http://creativecommons.org/licenses/by-sa/3.0/us/>.



Closures: Open Issues (v0.6b)

   - *The specification does not define the classfile format for the "for"
   qualifier.*
   - *The for keyword on a method declaration should be a qualifier.*
   Meant to introduce a control abstraction method that works like a loop,
   "for" should be treated syntactically like a modifier rather than appearing
   immediately before the method name. This helps make the declaration site
   more similar to the use site.
   - *Relax the closure conversion.*
   The closure conversion requires that the parameters of a closure exactly
   match the parameter types of the interface it is converted to. Experience
   with the 0.5 prototype suggests that this should be relaxed to an assignment
   conversion.
   - *Control transfers from a lambda.*
   We should describe in nonnormative text the techniques used in the
   prototype to implement control transfers out of an expression lambda.

------------------------------
[image: Creative Commons
License]<http://creativecommons.org/licenses/by-sa/3.0/us/>
Closures for Java by Neal Gafter and Peter von der
Ahé<http://www.javac.info/>is licensed under a Creative
Commons Attribution-Share Alike 3.0 United States
License<http://creativecommons.org/licenses/by-sa/3.0/us/>.