"Yigal Chripun" <yigal...@gmail.com> wrote in message
news:gmd0u8$fg...@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: "func(someInt) { |a,b| return a+b; };" )
).
