[DGD] lambda operator re-re-visited?

[Carter Cheng]

I am not sure I see a good alternative unless some special semantics is
introduced to somehow track anonymous objects so that when a recompile
occurs the system knows which lambda functions to assign to which variables
on a given recompile.

But your point is taken. There should be some method for "collecting" all
lambdas associated with a given program version so that one can upgrade
them as needed. I.e. when the program recompiles a broadcast signal should
be sent to all extant lambdas associated with the program to see if they
need recompiling as well. Kind of like how upgrade cycles through extant
objects.



On Wed, Jan 4, 2017 at 2:18 AM, Felix A. Croes <felix at dworkin.nl> wrote:

> Carter Cheng <cartercheng at gmail.com> wrote:
>
> > My thought on this is to not recompile L when A is recompiled since
> lambda
> > operators are runtime operators and should have the illusion of creating
> > the function on the spot.
>
> Scenario: you're patching a low-level inherited object to fix a security
> bug.  Unrecompiled anonymous functions will inherit old code, and thus be
> a security problem.
>
> Scenario: you're patching a low-level object to reflect an interface
> change.
> Unrecompiled anonymous functions will attempt to use the old interface, and
> will no longer work.
>
> Giving up system-wide full recompilation of all objects and functions to
> provide the illusion of creating functions on the spot seems like a poor
> trade-off.
>
> Regards,
> Felix Croes
> ____________________________________________
> https://mail.dworkin.nl/mailman/listinfo/dgd
>