Closures are pointers to methods or blocks of code that capture the environment in which they are defined. They are most likely coming to Java soon. Now which nemesis would you prefer?

Java* or {=>Java}

Psychologically it’d be a desaster to introduce the *pointer-style to java because everyone will think that their nemesis has finally arrived in java to make them roast on a hellish fire. Painful.

@Talden,

The TYPE part of the variable declaration using this pointer syntax can be defined as follows:

ReturnType* ((p1, p2, …pN) throws e1, e2, …eN)

Consider the following Java method signature that accepts two parameters of type File and int, returns a String, and throws an IOException

String (File, int) throws IOException

Closures for this method would be declared as follows:

BGGA syntax:
{File, int => String throws IOException}

Pointer syntax:
String* ((File, int) throws IOException)

Stephen Colebourne’s generic BGGA converter example (used in this post) both accepts and returns closures. Lets add exceptions to that and compare:

BGGA syntax:

public {T => U throws E} converter({=> T} a, {=> U} b, {T => U throws E} c) {
  return {T t => a.invoke().equals(t) ? b.invoke() : c.invoke(t)};
}

Pointer syntax:

public U* ((T) throws E) converter(T* a, U* b, U* ((T) throws E) c) {
  return (T t) {a.invoke().equals(t) ? b.invoke() : c.invoke(t)};
}

@Xavi,

Thanks for your explanation. The BGGA syntax certainly does have a certain clarity about it. I think a lot of people would agree that as far as initial impressions go, both look rather cryptic.

@Alain,

You are scaring me when you use names like funcPtr
I do agree with your summary in that the syntax should look very Java method like and should (unlike C/C++) enforce the principle that the variable name should be the last token.

for naive user the star symbol represent the wildcard symbol replacing the name of a function.
aestically the star symbol seems a bit strange… but if you interpret it a a wildcard/replace-me-with-a-function-name, it is much better than other.
aestically I’ve seen the “#” not so bad, but # is a comment mark.
why not the ?, it is a wildcard like *, and is already used for templates, :
int ?(int x) throws Exception funcPtr;

another solution might be to use a reserved word, but I konw java have compatibility problems.
int function (int param) thows XException;
maybe magic anotation
int @function (int param) thows XException;
but break annotation logic. or just sugar word after star or #
int *function (int param) thows XException funPtr;
int #function (int param) thows XException funPtr;
why not the ?

also Template way seems interesting
java.lang.Function pricer;
but it is awful about return type (not clear it returns double), and cannot manage Exception throws (for me it is essential to support what is supported with Interface

my summary :
-syntax should enforce the principle that the variablename should be the last token before equal or semicolon.
- should support throws, and parameter name as Interface Method
- syntax should look like normal method declaration
- should be simple to parse
- Template does not support throws and parameter names. bad.

these are cognitive equivalents :
int *(int param) throws MathException myFunc= {return 100/param;};
int #(int param) throws MathException myFunc= {return 100/param;};
int ?(int param) throws MathException myFunc= {return 100/param;};
considering ? is used already for template, my heart goes to ‘?’, the ‘*’ as a wildcard mark, then ‘#’ that despite beeing a comment mark in many language is beautiful.

the invoke syntax is an orthogonal problem.
compared to C/C++, java make pointer logic disapear
Object *a=new A(); a->doIt();
became
Object a=new A(); a.doIt()
int (*funcPtr)(int param); int result=(*funcPtr)(3)
shoudl bacame
int ?(int param) funcPtr; int result=funcPtr(3);
there is an ambiguity
if a method funcPtr(int x) exist, and also a func Pointer funcPtr; as told here java had never any such ambiguity with homonymous.

for me
int result=funcPtr.invoke(3) is not so bad… it is really java spirit where we prefer to have method that operators.

calling syntax funcPtr(3) might be acceptable as a syntax sugar when there is no ambiguity, but is it worth ? I love that in java many things stay a little verbose, showing that things are not so simple.

so I vote for .invoke(…) as it explains that func pointer is used and it is not trivial.

I haven’t explained clear enough what I wanted to say (my comment is not very clear, I should have written it better). For me it is clearer the non-pointer syntax (with “=>”) _but_ it doesn’t look like Java-ish, perhaps because Java has shared a lot of syntax with C and C doesn’t have this “=>” syntax.

The pointer syntax may be more Java-ish but, IMHO, it is cryptic and not so clear as the “=>” syntax. That’s why I prefer the “=>” syntax.

For example, in the example you have written, I see much clearer the “{int => boolean}” syntax than the “boolean* (int)” one.

Regards,

Xavi

A java variable declaration (if you ignore the c-style array notation) is always:

TYPE IDENTIFIER [= INITIALISER]

I would prefer to retain the “I am declaring a variable of type TYPE called IDENTIFIER whose initial value is INITIALISER” structure. I’m even content to go down the FCM path to get it over what is being proposed here.

To the “familiar ‘*’ symbol already used in C” statement I say… Go program in C. I always disliked the function pointer notation in C and no amount of “*” is going to fix that.

And when you’re doing these examples please include one with exceptions and one that accepts and returns closures – as the notation needs to provide for both of these and combinations thereof.

boolean (int)
void ()
<T,U> T (U)


Does this

{int => boolean}
{=> void}
{U => T}


look more Java-ish than this?

boolean* (int)
void*
T* (U)