On 09/25/2011 11:43 AM, Mafi wrote:
Am 22.09.2011 22:54, schrieb Andrei Alexandrescu:
On 9/21/11 5:17 PM, Walter Bright wrote:
I've collected a few from various languages for comparison:
[snip]
I think we should do the following:
1. Introduce a new token "=>"
2. Add this rewrite to the grammar:
symbol => expression
translates to
(symbol) { return expression; }
3. Add this rewrite to the grammar:
symbol1 symbol2 => expression
translates to
(symbol1 symbol2) { return expression; }
4. Add this rewrite to the grammar:
(comma_separated_parms) => expression
translates to
(comma_separated_parms) => expression
Each item in comma_separated_parms may be 1 or 2 symbols separated by
whitespace. Example:
(int a, b) => a + b
is valid and translates to (int a, b) { return a + b; }
5. The expression cannot contain commas at top level; an unparenthesized
comma is considered to finish expression, just like in a function call's
argument list. For example:
fun(int a => a + 1, a + 2)
is interpreted as
fun((int a => a + 1), (a + 2))
To use comma inside expression, add parens around it.
5. Remove bugs and limitations. A function literal may specify none,
all, or some parameter types, and the compiler correctly figures out the
appropriate template and non-template parameters. The literal
subsequently converts to function pointer or delegate whenever there's a
match of parameter and result types.
Andrei
If we decide to add something like this, the => 'operator' has in my
opinion to have a higher precidence thand ! or you should be able to
write it at least without parenthesis (using other parser tricks).
Like this:
map!x=>x+1(list)
It cannot have higher precedence than !, because then your example would
be parsed as
(map!(x=>x))+(1(list))
Other parser tricks are impossible, because:
map!(x=>x+y(list))
and
map!(x=>x+y)(list)
cannot be distinguished without parens.
