Preparing for the 0.2 draft

[Stefan Schulz]

Am 29.01.2010 09:56, schrieb Alex Buckley:
> Many thanks for everyone's comments on the 0.1 draft. The "foo.()"
> invocation syntax looks like a winner,

-1
It really looks like a syntax error and I don't think it's worth it only 
for removing additional, e.g., two characters. It might also be of 
interest to invoke other "methods" on a lambda, e.g., getType() or curry()*

 > and I am seriously considering
> rearranging the function type syntax to have argument types first.

Why is that? I did not see any real argument for it.

What I read from several replies is that there might be the need for a 
better distinctability between lambda and function type. Both not 
necessarily have to use the same syntax, but it would be nice to have a 
resemblance. Especially for higher level lambdas, it might be better to 
brace a function type declaration. So maybe a notation like follows 
would help:

   [[int(int,int)]() throws NoSuchOperation] operations = ...;

Which would be somewhat like:

   FunctionType:
     '[' ResultType '(' TypeList_opt ')' Throws_opt ']'

I don't know, if there are conflicts with Array definition or the 
proposed collection literals. I think a compiler should be able to 
distinct between both. Of course, one could add a mandatory '#' for a 
function type.

> Requiring a lambda expression to denote its return type is also
> increasingly appealing.

I'd expect for a lambda that a compiler is able to infer its return type 
as well as its checked exceptions thrown. Hence, there is no need to 
define either for a lambda. The optimum would be to infer the argument 
types as well, but that seems too difficult to do.

Cheers,
Stefan

*) see, e.g., http://ur.ly/3YQT for examples and applications on 
"currying" a lambda/closure