[DGD] lambda operator re-re-visited?

[Carter Cheng]

I think breaking the anonymity a bit for the purposes of recompilation
might be a possible solution. I.e. associating something like a file path
and line number with some extra discriminant to each closure's metadata and
having a way to locate the anonymous functions associated with a given
piece of source.

That way when the system attempts to upgrade or recompile the original
program it can propagate through an lpc hook to the anonymous programs
which then gives the system the option of recompiling them with new code
specified by the system.

On Thu, Jan 5, 2017 at 5:50 AM, Dread Quixadhal <quixadhal at gmail.com> wrote:

> To be fair, I said that exporting an anonymous function is a design mistake
> if you can't (or don't) update the reference when you are recompiled.  In
> my example, SetLong() needs to be called again from the on_update()
> function (or whatever your mudlib does when a recompile happens).
>
> Let's look at the input chaining usage.
>
> A menu system would obviously make use of this, since you'd want to
> generate the list of valid options on the fly, as you walk the menus.
>
> So, your user is picking off a menu when the object that presented the menu
> gets recompiled.  Presumably, the driver will attempt to call the old
> version of their current menu step when the next line of input shows up.
> Because the menu system is generic, it can't easily inform the user object
> of the updated code, since it doesn't know where that particular user is,
> in their menu walking.
>
> What would happen?  If you did nothing, the old version of the menu would
> be called with the user having input a choice based on the old options,
> which may now mean something different.  Maybe they picked "rename
> character" which is now "delete character".
>
> If you caused the old function to become nil, presumably the driver would
> generate an error trying to call nil as a function.  The input handler
> would have to catch that and restore the default input handler.  The user
> would likely end up confused, as they just fell out of the menu and are
> back at a normal prompt.
>
> Either way, the user won't be very happy.  But is that a good reason to not
> have anonymous functions at all?  It's a good reason to make sure anyone
> using them understands their limitations, to be sure.
>
> The ideal solution would be for the freshly recompiled menu object's
> on_update() function to change the user's input_to() hook... but that's
> likely not possible, since the object would lack the specific user's input
> data to know how to do that.
>
> It is possible to have anonymous functions that would be useful, if the
> user were careful and understood the implications of using them in a
> persistent system. But if you require a 100% bulletproof solution for every
> conceivable use case, then I'll stop commenting here, because I don't think
> it's possible.  Like the old strtok() function from the C standard library,
> it can be very handy, and it can hurt you badly if you don't know what it
> does.
>
> Cheers!
> ____________________________________________
> https://mail.dworkin.nl/mailman/listinfo/dgd