[DGD] lambda operator re-re-visited?

[Dread Quixadhal]

On Wed, Jan 4, 2017 at 12:58 PM, Felix A. Croes <felix at dworkin.nl> wrote:

> In the posting that you first responded to, I pointed out a problem
> with recompiling closures for which the source code can be retrieved.
> How do you propose to solve this problem?


An anonymous function isn't really anonymous.  It's basically a function
which wasn't given a name, but you could refer to it internally by a
generated name.  Correct?

So, object A exports a function, F, that object B uses.  Object A gets
recompiled, causing that function, F,  to change into G, or perhaps
disappear entirely.

Should object B continue to be able to call function F, even though doing
so may cause a run-time error if F references things in A which may have
changed or disappeared?

Or, should object B's reference to F be moved to G, even though doing so
may cause issues for B, since G may now be doing something different than B
expected it to do?  We already discussed how difficult this would be a year
or two ago, and pretty much agreed that it's not practical if more than a
single anonymous function were involved.

But, let me give a small example of a common usage pattern in a FluffOS
based mudlib, to try and clarify the other case.

In a room object, I have a bit of code in the create() function that does:

SetLong( (: some code here :) );

This sets the room's long description to run that anonymous function
whenever something tries to get the description, via GetLong().  In this
case, it modifies the room description based on what the person who is
looking at it should be able to see.

So, the room object would be object A, with anonymous function F.  The
library code for GetLong() would be our object B here.

When create() is called, SetLong() hands a reference to F to something in
the black box of LIB_ROOM.  When anything else later calls GetLong() on
object A, it evaluates F again and returns the result.

If object A gets recompiled without being destructed, create() doesn't get
called again, so SetLong() can't hand off a reference to our new anonymous
function G.  In that case, when someone wanders along and invokes
GetLong(), it will either generate wrong data, or maybe a run-time error if
the code in F tries to reference something now invalid.

This is not a problem with F or G.  This is a design mistake on the part of
the author of object A.  Namely, if you expect an object to be recompiled
without being destructed, the call to SetLong() should be in a function
which gets called on such an update as well as in create().

TL;DR version:  references to anonymous functions don't just magically
appear in other objects.  Some code in object A had to hand that reference
to object B, and IMHO it's on the author of A to ensure that those
references get refreshed.  So, I guess I'm saying I don't see it as a
problem, but rather a caveat that the user needs to be aware of when using
anonymous functions in a persistent environment.