Use:
    final Method0< R, RuntimeException > method1 = new Method0< R, RuntimeException >() { 
      public void call() { ... }
      public String toString() { return "Method1"; }
    } );
    final Method0< R, RuntimeException > method2 = new Method0< R, RuntimeException >() { 
      public void call() { ... }
      public String toString() { return "Method2"; }
    } );
    time( method1, method2 );

Given:
  public interface Method0< R, Ts extends Throwable > { R call() throws Ts; }
  ...
    public static < R, Ts extends Throwable > void time( final Method0< R, Ts >... methods ) throws Ts {
      for ( final Method0< R, Ts > m : methods ) {
        final long start = currentTimeMillis();
        final R result = m.call();
        final long end = currentTimeMillis();
        out.println( m + " returned " + result + " and took " + (end - start) + " ms." );
      }
    }

Use:
    final method1 = Method0.new { 
      method call { ... }
      method toString { "Method1" }
    };
    final method2 = Method0.new { 
      method call { ... }
      method toString { "Method2" }
    };
    time method1, method2;

Or shorter:
    time new { 
      method call { ... }
      method toString { "Method1" }
    }, new { 
      method call { ... }
      method toString { "Method2" }
    };

Or shorter still:
    time enum { 
      Method1 { method { ... } },
      Method2 { method { ... } }
    }.values;

Given:
  public interface< R, Throwable... Ts > Method0 { method R call throws Ts }
  ...
    public static method< R, Throwable... Ts > void time( final Method0< R, Ts >... methods ) throws Ts {
      for ( final m : methods ) {
        final start = currentTimeMillis;
        final result = m.call;
        final end = currentTimeMillis;
        out.println m + " returned " + result + " and took " + (end - start) + " ms."
      }
    }

Use:
    withLock(lock, new Block0() {
      public Void call() { out.println( "Hello" ); } 
    });

Given:
  public interface Block0extends Throwable> extends Method0 {}
  ...
    public static extends Throwable> void withLock(Lock lock, Block0 block) throws Ts {
      try {
        lock.lock();
        block.call();
      }
      finally { lock.unlock }
    }

C³S withLock

Use:
    withLock lock, method { out.println "Hello" };

Given:
  public interface Block0 extends Method0<Void, Ts> {}
  ...
    public static method void withLock(Lock lock, Block0 block) throws Ts {
      try {
        lock.lock;
        block.call
      }
      finally { lock.unlock }
    }

Java each

Method each steps through each item in a collection. The example assumes that collections are given new members functions (i.e. each) and given vararg constructors. (However, modifying the collections library is really a separate issue to C³S.) The example uses short names and is shown with minimum white space and it inlines definitions. I don't consider this extra short formatting realistic; but it is used in other blogs, some people prefer it, and a proposal must look OK in many different formatting styles.

Use:
    final ArrayList list=new ArrayList(1,2,3);
    final Tuple1 sum=new Tuple1(0);
    list.each(new Block1(){
      public void call(x){sum.e1+=x;}
    });

Given:
  public class Tuple1{
    public E1 e1;
Tuple1(E1 e1){this.e1=e1;}
  }
  ...
  public interface Block1extends Throwable>extends Method1{}
  ...
    public extends Throwable> void each(Block1 b)throws Ts{
      for(E e:es){b.call(e)}
    }

C³S each

Use:
    final list=ArrayList.new(1,2,3);
    declare sum=0;
    list.each method(x){sum+=x};

Given:
  ...
    public method void each(Method1.interface{} b)throws Ts{
      for(final e:es){b.call(e)}
    }

Summary

Whilst the syntax proposed is not the shortest possible; I think it is the best proposal to date because it balances: Clarity, Consistency, and Conciseness and because it unifies previous proposals. The syntax synergy of the proposal is demonstrated in the table below (syntax in table slightly simplified to keep table short).

Modifiersopt Keyword< ... >opt Typeopt Nameopt Extrasopt ( ... )opt { ... ; ... }

             if                                         ( ... )    { ... ; ... }

Modifiersopt class< ... >opt          Nameopt Extrasopt             { ... ; ... }

Modifiersopt method< ... >opt  Typeopt Nameopt Extrasopt ( ... )opt { ... ; ... }

Modifiersopt final< ... >opt   Typeopt Name                           ... , ... ;

     Type.optKeyword< ... >opt Typeopt Nameopt Extrasopt ( ... )opt { ... ; ... }

     Type.optinterface                                             { ... ; ... }

     Type.optmethod< ... >opt  Typeopt Nameopt Extrasopt ( ... )opt { ... ; ... }

What do other people think – is this syntax an improvement on the other proposals? Does this proposal unify the other proposals?

Appendix 1 – C³S Rules

Stage 1

The concept is to implement stage 1 rules and then see if stage 2 suggestions are still considered necessary.

Rule 0: For a method call allow brackets, (), to be omitted if there are no arguments and for the last call in a chain of Top Level calls (method, constructor, or modified new, see Rules 2 and 3 below); provided that the call isn't ambiguous with respect to a field. Top Level means the call isn't an argument to another call. Note braces start a new statement with a new top level. The last call means that for the top level calls only: it is either the only call (and that call isn't qualified) or it is the call following the last dot. The last call rule means it must follow the last dot, even if that dot is a qualifier dot rather than a call dot; so that an integer argument is distinct from a real argument (see last example Rule 3). This rule is more concise. E.g.:

     size = list.size;
     list.set 0, 'A';
     list.add( 'A' ).add 'B';
     list.add string.charAt( 0 );

Rule 1: Allow final and a new keyword, declare, to infer the type of a declaration based on the initial value. If no initial value is given or the value is given as null then the type must be specified as normal (also the declare keyword may be used like final is currently used). Function arguments are as is, except that declare may prefix the declaration to emphasize that the parameter isn't final. To specify primitives the type must explicitly be given, see first example below. Generic arguments follow the keyword and are useful for recursive or repeated types. This rule improves clarity by using a keyword, consistency by always using a keyword and allowing generic parameters, and conciseness of by allowing type inference. E.g. (also see rules 2 and 3 for new new notation):

     declare sum = 0; // Integer, for int use: int sum = 0 or declare int sum = 0
     final< X > Tuple2< X, X > duplicate; // Not the same as Tuple< ?, ? >!
     declare strings = ArrayList< String >.new.add "A";
     final strings = ArrayList< String >.new;

Rule 2: Allow new to be used as a qualifier with a . (dot) like a static method call (but generic arguments retain their normal position after the type) instead of as a prefix operator. This rule improves readability and hence clarity since it tightly associated with the type, is more consistent with the rest of Java, and (importantly) enables Rule 3. E.g.:

     declare strings = ArrayList< String >.new( "a", "b", "c" ); // Assuming ArrayList had a vararg constructor!
     declare numbers = (T[])Number.new[ 1 ]; // where T extends Number

Rule 3: Allow new to infer generic type from constructor argument and use <> to mean a raw type. This rule considerably shortens generic declarations and also instances of anonymous inner classes. E.g.:

     declare strings = ArrayList<>.new; // Explicit raw type
     final strings = ArrayList< String >.new; // Explicit generic type
     final strings = ArrayList.new( "a", "b", "c" ); // Inferred generic type, assuming vararg constructor

Rule 4: Allow new to declare constructors in classes and to infer argument types from fields of the same name if no argument types are given (like final and declare do for variables – see Rule 1). If argument names are given without qualification and body is given as default then infer a simple Assignment of arguments to fields. This inferring of Assignment is similar default functionality to ML, Scala, and Fortress, but is more flexible since multiple constructors with different access and annotation modifiers are possible. Inside an instance method the notation this.new( ... )_opt may be used. This use of new improves clarity since new is a keyword, improves consistency since it emphasizes the similarity between constructors and static methods and is consistent with the new use of .new after a type name (Rule 2), and is more concise. E.g. (also see Rule 5 for omitting trailing ; and Rule 15 for position of generic arguments):

     class< E1 > T1 {
       declare E1 i;
       new( final E1 i ) { this.i = i }
     }

     class< E1 > T1 {
       declare E1 i;
       new( final i ) { this.i = i } // Infer argument type from field
     }

     class< E1 > T1 {
       declare E1 i;
       new( i ) { default } // Infer argument type from field and infer copy of argument into field
     }

Rule 5: If an expression ends in } then there is no need for ; before the brace (like , in array initializers and also note , at end of argument lists is an error). IE treat ; as a statement separator rather than a statement terminator. This rule helps the readability of instances of anonymous classes and encourages braces to always be used even if a single statement is possible. E.g.:

     if ( end ) { break }

Rule 6: Introduce a new keyword, method, for declaring methods which is syntactically placed just before any generic parameters (i.e. Immediately after annotations and modifiers). If the method overrides a method then optionally infer @Override, other modifiers, return type, method argument types, and throws clause. If there is only one method to override then the method name can be inferred. If the method has no arguments the brackets may be omitted. This new keyword is clearer because it is a keyword, is more consistent because other declarations have keywords, and is more concise because it allows inference. E.g. (also see Rule 9 for new generic type syntax and Rule 12 for omitting keyword return):

     public static method< K, V > Map< K, V > unmodifiableMap( Map< K ?, V ? > map ) ...
     method toString { "Hello" }

Rule 7: Keyword, method, can also be used with a type followed by a dot notation to be a shorthand for creating an anonymous instance of an anonymous inner class. This new syntax is clearer because its intent is not obscured by verbosity, is more consistent because its syntax is like other blocks (e.g. if), and is more concise because of inference. E.g.:

     final action = AbstractAction.method ( final notUsed ) {
       controller.updateAllViews updateModel
     };

Rule 8: Keyword, method, can also be used to create anonymous instances of anonymous inner classes without a type and a dot notation if the type can be inferred from a methods arguments. This new syntax is clearer because its intent is not obscured by verbosity, is more consistent because its syntax is like other blocks (e.g. if), and is more concise because of inference. E.g.:

     final button = JButton.new method ( final notUsed ) {
       controller.updateAllViews updateModel
     };

Rule 9: Allow extends type generic arguments to be shortened to < Type name > (i.e. like normal variable declarations), e.g.:

     public static method< K, V > Map< K, V > unmodifiableMap( Map< K ?, V ? > map ) ...
     public class Enum< Enum< E > E > ...
 
   Which are equivalent to
     public static < K, V > Map< K, V > unmodifiableMap( Map< ? extends K, ? extends K > map ) ...
     public class Enum< E extends Enum< E > > ...

Rule 10: A throws clause can be empty, which means the method doesn't throw anything (equivalent to an absent throws clause). This is useful in conjunction with generics, see Rule 11 below. E.g.:

     method Void call() throws;

Rule 11: Generics are extended to allow varargs (only for use with Throwables and derivatives). An empty generics varargs list is allowed and it is equivalent to an absent throws clause (note Rule 10 above). E.g.:

     method< R, Throwable... Ts > R call() throws Ts;

Rule 12: Keyword return may be omitted for last line of a method and the returned value is the value of the last expression, e.g.:

     method toString { "Hello" };

Rule 13: If a method returns a Void, then make the end of a method without a return and a return without an argument synonymous with return null. E.g. the following are identical.

   Given:
     interface< Throwable... Ts > Block0 extends Method0< Void, Throwable... Ts > {}
   
  Then:
     final block = Block0.method {};
     final block = Block0.method { return };
     final block = Block0.method { return null };
     final block = Block0.new {
       method { return null }
     };
     final block = Block0.new {
       @Override method call { return null }
     };
     final block = Block0.new {
       method call { return null }
     };
     final Block0< RuntimeException > block = new Block0< RuntimeException >() {
       Void call() { return null; }
     };

  Are all the same.

Rule 14: Non-final locals that are referenced by an inner class are automatically wrapped in a final-tuple instance, like C# 3.0 does. Note: special treatment, name mangled temporary required, of non-final arguments is needed (not shown in example below). E.g.:

   Given:
     public class< E1 > Tuple1 {
       public E1 e1;
       public new( e1 ) { default }
     }
     public class< E1, E2 > Tuple2 extends Tuple1< E1 > ...
     public interface< R, A1, Throwable... Ts > Method1 { R call( A1 a1 ) throws Ts }
     public interface< A1, Throwable... Ts > Predicate1 extends Method1< Boolean, A1, Ts > {}
     ...
       public static method< T, Throwable... Ts > List< T > select( final Iterable< T > c, final Predicate1< T ?, Ts > f ) throws Ts ...
   
  Then:
     final beginning = "Fred";
     final names = ArrayList.new "Frederick";
     final filtered = names.select method ( name ) { name.startsWith beginning };
   
  Which is equivalent to the following verbose version:
     final Tuple1< String > beginning = new Tuple1< String >( "Fred" );
     ArrayList< String > names = (new ArrayList< String >( "Frederick" ));
     ArrayList< String > filtered = names.select( new Predicate1< String >() {
       public Boolean call( final String name ) {
         return name.startsWith( beginning.e1 );
       }
     } );

Rule 15: Allow generic parameters to follow keyword for class and interface, i.e. like method and like Type[] for arrays. This improves consistency since in some circumstances it cannot follow the name, e.g. method declarations. E.g.:

     public class< E1 > Tuple1 {
       public E1 e1;
       public new( e1 ) { default }
     }

Rule 16: Allow anonymous type declarations, TypeToExtend._optclass { ... }, for class, interface, and enum. This is intentionally similar syntax to anonymous instances of anonymous classes, i.e.: similar syntax to Type._optnew ( ... )_opt { ... } and Type._optmethod ( ... )_opt { ... }. If used as an initializer for a variable the type is inferred. as Class< $1 >. If used as a method argument the type to extend may be inferred. This is a useful generalization of the notion of creating anonymous instances of anonymous classes to the creation of anonymous types. E.g. (also see Rule 17):

    public method< Throwable... Ts > void each( final Method1< Void, E, Ts >.interface{} b )throws Ts {
      for ( final e : es ) { b.call( e ) }
    }

    final singleton = Method0.enum { // Singleton is of type Class< $1 > where $1 implements Method0 and is an Enum
      Method1 { method { ... } },
      Method2 { method { ... } }
    };
    time singleton.values;

    time enum { // Infer Method0
      Method1 { method { ... } },
      Method2 { method { ... } }
    }.values;

Rule 17: Allow static methods to be called on variables of type Class< T > using the normal dot notation. This is consistent with the concept that static members are what other languages call class members, e.g. smalltalk. E.g. (also see Rule 16):

    final singleton = Method0.enum { // Singleton is of type Class< $1 > where $1 implements Method0 and is an Enum
      Method1 { method { ... } },
      Method2 { method { ... } }
    };
    time singleton.values;

Rule 18: Allow variable declarations . E.g.:

    final singleton = Method0.enum { // Singleton is of type Class< $1 > where $1 implements Method0 and is an Enum
      Method1 { method { ... } },
      Method2 { method { ... } }
    };
    time singleton.values;

Stage 2

Having implemented stage 1 and gained some experience a second stage could be added with the following suggestions (these are very much suggestions and this section should be treated as a list of open issues). I have stuck with syntax related suggestions that are essentially sugar and no new semantics or modifications to JVM.

Suggestion A: Add support for statements break, continue, and exit multiple enclosing blocks using break, continue, or return. The syntax for break and continue for an enclosing loop would be unchanged. For exiting an enclosing method the syntax could be MethodName.return value;. This could be implemented using pre-made checked exceptions, thus allowing compile time checking of multiple block exits. Syntax could be unified by allowing Name.break and Name.continue and named blocks, e.g. if Name ( ... ) { ... }.

Suggestion B: Add support for long strings with embedded variables using a new keyword, string, e.g.:

    string { // Trailing white space and single new line on { line not part of string
Embed variables including optional formatting, e.g.: %2.1f{ real }
    } // Leading white space and single new line on } line not part of the string

Suggestion C: Add support for union of types using & like generics (particularly for catch blocks).

Suggestion D: Allow final and declare to be used for the variable declaration in a catch block and allow type inference as the union of all declared or inferred (checked or not) exceptions.

Suggestion E: Add support for properties by inferring bodies and declarations for: method getName { default }and method setName { default }; i.e. like new { default }.

Suggestion F: Universally allow () in C³S to be omitted, e.g. if condition { ... ; ... } and method Type name ..., ... { ... ; ... }.

Suggestion G: Unify variable (field, local, and argument) declarations around the standard syntax, e.g. final Type { name1; name2 }.

Suggestion H: Make new line act as a semicolon and allow ,, +, -, =, etc. as last non-white space or non-comment on a line to mean continued on next line.