Function types syntax

[Peter Levart]

On Tuesday 26 January 2010 00:49:18 Alex Buckley wrote:
> FunctionType:
>    '#' ResultType '(' [Type] ')' FunctionThrows_opt
> FunctionThrows:
>    '(' Throws ')'
> 
> #int(String)(throws java.io.IOException, java.sql.SQLException)
> 

I can't help myself, but more and more I look at the syntax for function types, I think it is terribly unreadable for specifying 2nd or higher order functions. You may argue that such usage will be rare, but nevertheles, if we add throws declarations to the mix...

##int(String)(throws IOException)(String)(throws SQLException)

...what is what? I realy have to "machine parse" it, to get it right. Maybe it's not to late to reconsider alternative syntaxes. The BGGA syntax was much more readable in this respect. Even if it didn't look like a Java method declaration, it felt natural. Your proposal already deviates from method declaration syntax by enclosing throws declarations in parentheses. They neither help nor hurt readability though.

So lately, the following BGGA-like syntax is on my mind:

FunctionType:
  '#' '(' [Type] ':' ResultType Throws_opt ')'

Simple examples look like this:

#(:void)
#(String: int throws ParseException)
#(int, int: int)

2nd order example from above repeated here for comparison:

##int(String)(throws IOException)(String)(throws SQLException)

with proposed syntax:

#(String: #(String: int throws IOException) throws SQLException)


I think that for a type, the syntax need not mimic method declaration syntax. Think of it in terms of equivalent generic interfaces. How would one write such types today:

Function0<Void>
Function1E<String, Integer, throws ParseException>
Function2<Integer, Integer, Integer>

Function1E<String, Function1E<String, Integer, throws IOException>, throws SQLException>


I think that even a die-hard Java programer could grasp this equivalence.

What do you think?

Regards, Peter


P.S.

The following is not something I'm proposing. It's just an idea I'm dreaming about:

The above function types syntax could be nicely paired with the following syntax for lambda expressions that John Rose already proposed in a similar form:

LambdaExpression:
  '#' '(' FormalParametersList_opt ResultParameter_opt ')' Block

ResultParameter:
  ':' FormalParameter


Examples:

#(:void) printHello = #() { System.out.println("Hello!"); };

#(String: void) printName = #(String name) { System.out.println(name); };

#(String: int throws ParseException) parseInt = #(String s: int i) {
  i = DecimalFormat.getIntegerInstance().parse(s).intValue();
};

#(int, int: int) add = #(int a, int b: int c) { c = a+b; };


Notice that "no return statements were harmed in this presentation" ;-)

And using this syntax they don't have to be harmed, ever. If "Block" is prefixed with a label:

LambdaExpression:
  '#' '(' FormalParametersList_opt ResultParameter_opt ')' Label_opt Block

Label:
  ':' Identifier

Then "return" from lambda becomes a familiar "break label". For 1st JDK7 release, non-local returns/breaks/continues could be disallowed but the path to future transparent lambda would stay open...