[DGD] lambda operator re-re-visited?

[Carter Cheng]

Further note- when the lambda program is upgraded it should be possible to
upgrade it's label. One idea is to just have the lambda associated
permanently with the original program for upgrading purposes and just map
labels to labels to upgrade the lambda program since figuring out line
numbers in the upgraded program isn't too difficult.

On Thu, Jan 5, 2017 at 6:24 AM, Carter Cheng <cartercheng at gmail.com> wrote:

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