Lambda syntax, etc

[Yigal Chripun]

Bill Baxter wrote:
> On Thu, Feb 5, 2009 at 7:26 AM, BCS<ao at pathlink.com>  wrote:
>> 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; };"
>
> I was about to say the same thing, but I think Yigal was just mixing
> two distinct suggestions together:
> 1) the trailing delegates proposal (aka ruby block) and
> 2) A ruby-like syntax for delegate literals : {|a,b| return a+b;}
>
> --bb

not exactly. the reason why I changed the syntax like that is because of 
templates. for example:
void func(T, int i)(T a, delegate int(int) dg) {...}
with your and BCS' proposal the above would be called like so:

func!(SomeType, 15)(someVar)(a,b){ return a+b; };

this is less clear, IMO.

besides, I really like Ruby's (and before that Smalltalk's) syntax to 
handle this. <g>

to Nick -
you mentioned the scoping problem with strings. Personally I *HATE* this 
use of strings. it has many issues which I already mentioned in previous 
posts.
to specifically address your point - what your looking for is called 
"Hygienic Macros" - http://en.wikipedia.org/wiki/Hygienic_macros

basically you want to control which arguments to your AST macro are 
evaluated at which scope. This i'd like to see implemented in D when AST 
macros are added.