Closures: Open Issues (v0.5)
- Make it easy to yield a result early from a closure. It should be as easy to yield a result early from a closure as returning from a method.
- Should support for currying be directly in the language? Bound method references?
- 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.
- VM support for null
The verifier already supports null, including in the verifiers, but
there is no way to specify null as a method argument or return type. We
need a way to specify null in a signature (that is, a new signature
letter).
- 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.
- Document the new unchecked Throwables for nonlocal transfers.
- Should javac detect the most common problematic interactions catching nonlocal transfers?
The
most likely case may be completely local within a single method, when a
nonlocal transfer has a try-catch between the transfer and its target.
- volatile on locals.
We should say it is allowed.
- How are class literals for function types formed?
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.
- Can or should javac inline some invocations of control abstraction APIs?
If
so, how will it decide which ones? Does the inlining happen at the
bytecode or source level? Will javac handle break/return/continue
efficiently when these are inlined? Or is this something should be left
for the VM to handle? (Hotspot already seems to handle the most
important cases)
- Do we need any new reflection support for closures?
For function types? For null? Probably not because of the information available in the defining (not bridge) methods.
- Should a labelled for control invocation statement interact with labelled break and continue?
- Should for be a modifier (before the return type in a method declaration) or appear next to the name?
- Would explicit VM support for nonlocal transfers improve performance?
- Should we request VM support for proper tail recursion?
- Should we support (parametric) polymorphic function types? Probably not.