[fpc-devel] Delphi anonymous methods

Martin lazarus at mfriebe.de
Mon Mar 4 17:34:05 CET 2013


On 04/03/2013 16:05, Alexander Klenin wrote:
> Anonymous functions (with good syntax, of course) fall in this category.
> The world recognized that fact -- rather slowly, to be sure, but
> remember that "while"s and "for"s
> also took decades to be accepted as standard constructs.
  I am not going to ask for proof of this statement (as for example in 
quotation of literature on the topic).
For the arguments sake, let's assume the above.

> No, my proposal (which was made in the previous thread in this topic)
> is following (all-caps denotes non-terminal):
> 1.1) A function of the form
>    function NAME(PARAMS): RETURNTYPE; begin Result := EXPRESSION; end;
> can be shortened to
>    function NAME(PARAMS): RETURNTYPE as EXPRESSION
IMHO that is not a good idea. It adds an additional construct, that 
every reader must know how to read. It does not add/save enough to be 
needed.

>> If you look for the most natural, pascal like (ignoring the part that
>> declaring a function inline, IMHO is not that)
>>
>>    ATree.VisitPreorder(TVisitor(Result := X + 5);
>>    ATree.VisitPreorder(TVisitor(begin Result := X + 5; end);
>>
>> You are type casting the code, into a procedure of the given type.
> There is certainly a merit in that, but it violates another Pascal
> "basic principle" -- "prefer keywords to symbols".
We could also use the new, have a constructor for everything 
(TArray.Create) style. Personally, the idea appals me, but
    TVisitor.Create(Result := x + 5)

Another way to avoid the "as"
   lambda(TVisitor) .... end

lambda acts as "begin" to the block, so there always must be an end.

> Also, note that you can not omit Result assignment,
> since ATree.VisitPreorder(TVisitor(X + 5)); is syntactically ambiguous.
> So it becomes
> ATree.VisitPreorder(TVisitor(Result := X + 5));
> vs
> ATree.VisitPreorder(lambda TVisitor as X + 5);
See above. The omission "of Result :=" is IMHO not desirable.

> Finally, I disagree with unbalanced parenthesis -- but that's probably a typo?
>

yes



More information about the fpc-devel mailing list