[DGD] lambda operator re-re-visited?

[Carter Cheng]

Actually this issue doesnt arise in either java lambdas or c++11/14 lambdas
with copy not reference semantics or fluffos either which shares the same
semantics and it goes a bit beyond just a syntax issue for fluffos since
the support includes special opcodes.

If lambda is to be included I don't see much in terms of useful
alternatives. My original post already mentioned the source code issue- I
feel that not being able to inspect the "source" of an object (unlike say
self/smalltalk systems) is not usually too big of a problem for programs
coming from files- but for anonymous functions it's a bit problematic since
you don't know anything really about what they do. See my original post.

On Wed, Jan 4, 2017 at 2:54 AM, Raymond Jennings <shentino at gmail.com> wrote:

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