On Mon, Mar 4, 2013 at 10:34 PM, Martin <laza...@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.
> 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.
> 4) As stated above, either a syntax to explicitly turn off a closure
> for anonymous procedure,
> or intelligent enough optimizer to do that automatically. I have
> some ideas on both fronts,
> but I suggest we first discuss previous points.
> IMHO explicit Syntax.
This is certainly easiest from implementation POV,
but have some smell of premature optimization.
> But in the recent light of discussions to keep pascal being Pascal,
> anonymous functions could be entirely mode delphi only.
> From the reasons for anonymous methods.
>
> in Delphi every local variable access becomes a reference to the
> frame object field,
> *even in the parent procedure*. So "nested" anonymous procedures,
> together with
> good inlining support, are crucial for the efficient implementation
> of, for example,
> various "ForEach" methods.
The efficiency argument was mostly to show that non-closure procedures
are useful,
see argument about anonymous procedures below :)
> 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.
Compare this to the concept of objects, or structured loops.
Both can be implemented by means of "simpler" features, namely
records+procedures and
conditional jumps.
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),
but (4) is powerful enough to really make functional-style programming
practically
useful (as opposed to theoretically possible).
This is similar to how "object" syntax is enough to make object-oriented
programming practical, while using "hand-made" VMTs is too cumbersome
and error-prone.
--
Alexander S. Klenin
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
