[DGD] lambda operator re-re-visited?

[Raymond Jennings]

What happens if a lambda's code tries to reference an object scope variable
that no longer exists because it was removed in the new version after
recompiling?

Do you a) cause the obsolete lambda to start throwing runtime errors if it
tries to use a "dangling reference" to a variable that doesn't exist?  b)
notice the lambda depending on a variable that isn't there and throw an
error during the recompile? c) some other solution?

An object's variables are stored in the dataspace block.  The control block
specifies the name, type, and scope of every variable defined in the source
code.  This information is also used during recompiles to form an upgrade
chain that DGD uses to convert dataspaces, and that is how old variables
are wiped and new variables are initialized.  So, once an object is
recompiled, a removed variable is simply gone, and any attempt to access it
in the dataspace will run into the problem of "where exactly IS the
variable?".  At most, if you want to preserve lambdas during a recompile
you'll have to keep track of enough information for the lambda to either
know where to find the variable (the recompile could have changed the
layout of the variable list in the dataspace), or notice that the variable
has been deleted and probably throw a runtime error if the lambda's old
code attempts to access it.

Also, you cannot compile code that references a non-existent variable.
That will cause the compile to reject the source code with one or more
compile errors, ending with a runtime error.

Also, that 'broadcast" signal would need to be handled by LPC somehow
unless DGD itself retains the source code it would need to recompile the
program.  DGD does not usually retain the source code after the program has
been compiled.  Once compile_object returns back to LPC from kfun land, all
the source code is forgotten and the only thing you have left is a control
block with a slab of fresh bytecode for the interpreter to step through at
runtime.

And I'm speaking in general terms of semantics.  Fluffos implementation is
a syntax issue for the compiler AFAIK.

As for what you should do, I should also point out that blocking a
recompile at the kfun level is probably a very bad idea.  Since you can
mask compile_object in LPC if needed to prevent the recompile, I'd leave it
as a matter of policy.

On Tue, Jan 3, 2017 at 10:36 AM, Carter Cheng <cartercheng at gmail.com> wrote:

> 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
> >
> ____________________________________________
> https://mail.dworkin.nl/mailman/listinfo/dgd