Anonymous procedures (Was: Re: [fpc-devel] for-in-index loop)

[Sven Barth]

On 26.01.2013 20:12, Alexander Klenin wrote:
> On Sun, Jan 27, 2013 at 3:10 AM, Sven Barth <pascaldragon at googlemail.com> wrote:
>> On 26.01.2013 16:34, Alexander Klenin wrote:
>>> Ok, then let's take just one step back:
>>> SomeProc(lambda TProc1 as Writeln(aArg));
>>>
>>> This way, but problems are solved -- procedure type is specified
>>> independently from the parameter type,
>>> and overload resolution will work.
>>
>> While the compiler would be satisfied by this, this nevertheless leaves the
>> problem that we (as in "the user of the language") don't really see where
>> the aArg comes from...
>>
>> I can already imagine many questions like the following appearing on the
>> mailing list:
>>
>> === quote begin ===
>>
>> type
>>    TMyProc = reference to function(aArg: Integer): String;
>>
>> procedure SomeProc(aArg: Integer);
>> begin
>>    SomeProcTakingTMyProc(lambda TMyProc as IntToStr(aArg));
>> end;
>>
>> Why doesn't the lambda expression return the value that's passed to
>> SomeProc, but something completely different?!
>>
>> === quote end ===
>
> This is quite similar to using "with" statement -- yes, name clashes
> are possible.
> Perhaps they should be disallowed, like currently it is impossible to
> declare local variable
> overriding class field (except in Delphi mode).
> In this case, user will have to revert to full syntax.

Could indeed be a solution...

>> What still bothers me a bit is the handling of result values... if we
>> require the code after the AS to be an EXPR we'd need to implicitely assign
>> the result value. What does now happen if the lambda's type does require a
>> return value, but we don't provide one? What the otherway round?
>
> I suggest the following:
> Shortcut for functions *require* expression as body,
> since the only correct single statement would be assignment to Result
> (or call to Exit with an argument).
> Shortcut for procedures *require* a statement.
> Of course, the statement may be a function call, but that does not
> matter for procedure.

That would work. It would need to be clearly documented though :)

>>> But in this case, perhaps you are right, how about (taking into
>>> account the discussion of lambda above):
>>>
>>> sum := a.Reduce with lambda TAdderFunc as a + b;
>>> or without type helpers:
>>> sum := Reduce with a, lambda TAdderFunc as a + b;
>
>> While I still don't know why you'd want to replace parenthesis I would
>> definitely prefer this syntax over any ":" you can throw at me ^^
>
> This is mostly to avoid JavaScript-style mixed closing brackets in nested calls:
>
> a.forEach(function (aelem) {
>    aelem.forEach(function (v) {
>      doSomething(v);
>    })
> });
>
> with the no-parenthisis extension, the Pascal equivalent may be
> (suppose the actual code is long, so "as" shortcut does not apply):
>
> a.forEach with lambda TAElemProc begin
>    AElem.forEach with lambda TIntegerProc begin
>      doSomething(v);
>    end;
> end;
>
> without the extension, the Pascal equivalent may be:
>
> a.forEach(lambda TAElemProc begin
>    AElem.forEach(lambda TIntegerProc begin
>      doSomething(v);
>    end);
> end);

Hmm... you know what: i don't care. :) As long as you don't use "special 
characters" I'd make no problems here (others might though...)

Regards,
Sven