[DGD] lambda operator re-re-visited?

[Felix A. Croes]

Dread Quixadhal <quixadhal at gmail.com> wrote:

>[...]
> 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.

You seem to have chosen not to recompile anonymous functions.


> 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.

It is not required to export an anonymous function for the problem to
occur.  It can happen with any anonymous function that persists beyond
the current task.

You say that exporting an anonymous function is a design mistake.  Do you
also say that letting an anonymous function persist beyond the current
task is a design mistake?  Note that this would rule out some common
uses of anonymous functions, such as input chaining (which in an event-
driven system must happen across different tasks).  If so, would it not
be better if all anonymous function instances become nil after the
current task has ended?

If persistent anonymous functions are not a mistake, then not recompiling
them in a persistent environment would be a disaster.  In my earlier
response to Carter, I explain why.

Regards,
Felix Croes