[fpc-devel] Delphi anonymous methods

[Martin]

On 04/03/2013 14:09, Alexander Klenin wrote:
> On Mon, Mar 4, 2013 at 10:34 PM, Martin <lazarus at mfriebe.de> wrote:
>>> Nevertheless, I agree what the implementation plan can be detailed even
>>> further:
>>> 1) Anonymous procedures *without* closures -- basically, just another
>>> syntax for nested procedures.
>>
>>
>> That might be interested for mode Delphi
> No, this would be incompatible -- in Delphi, anonymous procedures are
> the only syntax for closures.
> I was proposing the reverse -- do this on objfpc mode only.
My comment was about anonymous part:
- Any anonymous function, for {$mode delphi} only.
- {$mode objfpc} does not need any anonymous functions at all.

AS for extending anonymous functions in the delphi mode: I have no opinion.

>> 2) Named closures support -- while I do think that anonymous
>> procedures are useful,
>>
>> And this could be in mode FPC too. So "purists" can still enjoy closures.
>> But it keeps one of the thinks that make Pascal: Declaration is all done
>> before the code block starts.
> Of course, this should only be on mode FPC, since Delphi does not have
> named closures.
Yes, but doesnt hurt if it compiles. mode delphi does not need to be 
artificially restricted.

> The efficiency argument was mostly to show that non-closure procedures 
> are useful,
No argoment there. Both have there place


>> IMHO anonymous methods are a syntactical difference only. All functionality
>> can be done with named equivalents too.
> "syntactical difference" is a very broad concept. The whole notion of high-level
> programming language is one large pile of syntactical differences from
> machine code.
I did *not* mean to diminish the importance of the correct syntax. I 
merely tried to emphasis the point, that this thread is about 2 things:
- anonymous functions: which is mainly adding new syntax. There is 
little (if any) new functionality added.  You still have the same code. 
Only now you can put it in a different location.
- closures: which add new functionality.

> The important question is, whether the new syntax adds enough expressive power
> to justify the complexity it adds to the language?
> In the case of anonymous methods, my answer is "yes, but only with
> lambda or similar extension".
> Let's revisit a typical example of anonymous functions -- note that
> this example does NOT use closures
>    to avoid another confusion:
> 0) Suppose we have
> type
>    TVisitor = function (X: Integer): Integer;
>    TTree = class
>       procedure VisitPreorder(AVis: TVisitor);
>    end;
>
> 1) Current syntax:
> function AddFive(X: Integer): Integer; Result := X + 5; end;
> ATree.VisitPreorder(AddFive);
>
> 2) Delphi syntax:
> ATree.VisitPreorder(function (X: Integer): Integer; Result := X + 5; end;);
>
> 3) With "lambda" syntax:
> ATree.VisitPreorder(lambda TVisitor; Result := X + 5; end;);
>
> 3) With "as" syntax:
> ATree.VisitPreorder(function (X: Integer): Integer as X + 5);
>
> 4) With both "lambda" and "as" syntax:
> ATree.VisitPreorder(lambda TVisitor as X + 5);
>
> Now, my argument is that (2) does indeed have only a marginal
> advantage over (1),
IMHO it does not. Except for, currently "AddFive" can not be a nested 
procedure. If we could use a nested (none closure) procedure here, then 
I would prefer this.
However I agree, this is subjective preference.

> but (4) is powerful enough to really make functional-style programming
> practically
>

I can live with that. I find it odd so that "as" is used in the reverse 
order compared to current use.