> On Apr 27, 2021, at 11:36 PM, Sven Barth <pascaldra...@googlemail.com> wrote:
>
> Anyway, it would in principle be possible to convert an anonymous function to
> a "is nested" function, but that will only come *after* the whole
> implementation is here so that the chance for messing that core functionality
> (!) up is reduced.
Sorry I'm struggling with all these new terms myself. Yes that is what I'm
proposing and what I demonstrated in that GitHub branch. We talked about this
in 2018 but you said to wait until the "real thing" was finished so I let it
be. I brought this up again now to say that when, and not before, the closures
are finished and in trunk I will see how to integrate the "nested anonymous
functions" into the new system.
To clarify for myself, we have a few concepts here:
- Closures: blocks which capture variables in scope and wrap them into a
container (nested functions use a record I think and closures will use an
interface).
- Anonymous procedures: Simply an anonymous procedure/function body which lacks
a name and can be declared inside code blocks.
- 2 Procedure types: "reference to" and "is nested". On the caller side these
are what control which kind of closure is used is used. Is that correct? So the
anonymous function doesn't really become a closure until it's passed to a
"reference to" or "is nested" variable.
So once the current work is done we have 2 kinds of closures but only one of
those is compatible with anonymous functions and this is why I want the other
closures (nested functions) to have the same pair of functionality.
Regards,
Ryan Joseph
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
