Lambda syntax, etc

[BCS]

Reply to Nick,

> "Yigal Chripun" <yigal100 at gmail.com> wrote in message
> news:gmd0u8$fg7$1 at digitalmars.com...
> 
>> Andrei Alexandrescu wrote:
>> 
>>> BCS wrote:
>>> 
>>>> Hello bearophile,
>>>> 
>>>>> I've taken a look at the syntax for lambda in other C-like
>>>>> languages. This is from Functional Java:
>>>>> http://functionaljava.org/examples#Array.filter
>>>>> 
>>>>> In Functional Java you can write this D syntax:
>>>>> (int i, int j) { return i % 3 == j; }
>>>>> as:
>>>>> { int i, int j => i % 3 == j }
>>>> That syntax, and a few of the below, show the one major gripe I
>>>> have with ultra-compact lambdas: it's hard to *quickly* spot the
>>>> args/code transition.
>>>> 
>>> Strings are immune from the problem. :o) Also they make for readily
>>> recognizable code because they all use the same argument names.
>>> 
>>> Andrei
>>> 
>> Personally I prefer to have syntax for "blocks" like Ruby/smalltalk.
>> given the following example function:
>> int func(int a, delegate int(int) dg) { .. }
>> // call func with [something in this spirit is my favorite]:
>> func(someInt) { | int a, int b | return a+b; };
>> 
>> compare with the current D syntax:
>> func( someInt, (int a, int b) {return a+b;} );
>> compare with a lamda syntax:
>> func(someInt, { int a, int b => a+b } );
>> blocks are more useful - they are not limited to just one expression,
>> and I think are a more general construct. lamdas/array comps, are
>> just special cases.
>> 
> Agreed. This is what I had always been ultimately hoping for. I'd be
> happy with the string stuff if that "wrong scope" issue gets fixed
> (that I mentioned in another branch of this thread), but I'd still
> prefer this (especially if the types for the params could somehow be
> inferred and omitted like this: 
> )
> 
> ).
> 

Why use this:

"func(someInt) { |a,b| return a+b; };"

when you can reuse syntax and get this for the same amount of typeing

"func(someInt) (a,b){ return a+b; };"