DRAFT PROPOSAL: Implementing Modified CICE and Block-Attached Calling

[Neal Gafter]

Using an annotation as proposed to change the semantics of the core
(non-annotation) language elements is in direct contradiction to the
design principles of the annotation language feature.

For "when used as arguments, the type part is optional", it is unclear
how this is intended to work with overloading.  How can the block be
semantically analyzed if you don't know what the parent class is, and
therefore you don't know what names are inherited?  Isn't that
semantic analysis necessary to find the applicable overloadings?

For the invocation syntax "shorthand", it is unclear what the scoping
is within the "block".  For example, what does a return statement
return from?  What does "this" mean?

Generally speaking, I think any proposal to implement a language
extension should have a more precise specification of the language
change before being submitted as an implementation project.

Regards,
Neal

On Sat, Mar 1, 2008 at 12:10 PM, Haitao Sun <remaker at devtaste.com> wrote:
>                         DRAFT PROPOSAL
>
>       Implementing Modified CICE and Block-Attached Calling
>
>                           SUN Haitao
>
>  I propose implementing a Java compiler with the following features:
>
>  * A new form of instance creating expression base on CICE[2] (with
>  some modification).
>
>  * A general control abstraction mechanism called "Block-Attached
>  Calling" (like "blocks"[1] in Ruby).
>
>  * An annotation to indicate the "major" method of concrete classes.
>  (So they can be treat like single-abstract-method types)
>
>  1. Design Goals
>  ===============
>
>  The major goal of this proposal is to try to add an expressive
>  control abstraction mechanism to Java in an easy-to-grasp way.
>
>  The minor goal of this proposal is to try to find out an attractive
>  solution for those who don't want closures in Java 7.
>
>  A mechanism which is not expressive enough often is bundled with the
>  following problems:
>
>  1) It can't express some useful abstractions. That takes programs
>  both hard to write and hard to read.
>
>  2) It's not cool enough. Then no one want trying it in early stage.
>  Without hundreds of thousands explorers, it's pretty hard to know
>  the feature's potentials, limitations, and proper usage.
>
>  3) Similar mechanism will be introduced again and again to express
>  more. That hurts orthogonality and brings complexity.
>
>  A mechanism which is not easy-to-grasp enough often have the
>  following short-comings:
>
>  1) It's hard to learn. It's certainly that developers smart enough
>  can handle this, but focusing their wisdom on real problems will
>  create a much better world.
>
>  2) It's hard to implement and optimize. The absence of optimized
>  implementation will prolong adoption cycle, and being adopted fast is
>  a key to success in market.
>
>  2. Introductions
>  ================
>
>  All three features proposed are inspired by original CICE proposal.
>
>  1.1 The modified CICE
>
>  I propose the following modification to CICE:
>
>  1) For concrete classes, the name of method to be override can be used
>  to solve ambiguity.
>
>  2) When using as arguments, the type part is optional.
>
>  1.2 the BAC mechanism
>
>  I propose a mechanism called Block-Attached Calling. It works like
>  Ruby blocks. So we can test whether mechanisms to define control
>  constructs are worth adding.
>
>  The main idea of BAC is that if the last argument is an CICE, its body
>  can be placed after the right parenthesis of the method calling. If
>  there is a formal parameter list, quotes it with "|" and use it as the
>  last argument.
>
>  If we adopt this proposal, we can write the following code slices:
>
>     // Loop Abstraction
>     // ``repeat`` is an user-defined method
>     repeat(3, |int i|) {
>         //do something
>     }
>
>     // Resource Management
>     // ``with`` is an user-defined method
>     with(resource) {
>         //do something
>     }
>
>  There is no public draft specification of BAC yet.
>
>  1.3 The "major" Annotation
>
>  I propose an annotation called "major" to indicate the "major" method
>  of concrete classes.
>
>  Concrete classes with one method annotated as "major" can be treat
>  like single-abstract-method types. The "major" method be treat as the
>  single abstract method.
>
>  3. Deliverables
>  ===============
>
>  The planned deliverables are:
>
>  1) The specification of the Block-Attached Calling mechanism and the
>  modified CICE.
>
>  2) The source code of the prototype compiler and related test suite.
>
>  3) The implementation and javadoc of the "major" annotation.
>
>  4. Existing Works
>  =================
>
>  The compiler will based on an SVN version of the compiler in OpenJDK.
>
>  Some ideas may be inspired by BGGA[3] proposal and FCM[4] proposal.
>
>  5. Dependencies on Sun
>  ======================
>
>  There are no known dependencies on Sun with following exceptions:
>
>  * The compiler is based on the compiler in OpenJDK.
>
>  * "SUN" happens to be my surname.
>
>  6. Related Works
>  ================
>
>  [1] Programming Ruby
>     http://ruby-doc.org/docs/ProgrammingRuby/html/tut_containers.html
>  [2] Concise Instance Creation Expressions: Closures without Complexity
>     http://docs.google.com/View?docid=k73_1ggr36h
>  [3] Closures for the Java Programming Language
>     http://javac.info/
>  [4] First-Class Methods
>     http://docs.google.com/View?docid=ddhp95vd_0f7mcns
>