[DGD] lambda operator re-re-visited?

[Raymond Jennings]

I think this dovedtails nicely into why Skotoslib uses SAM and Merry
instead of lambdas :)

On Wed, Jan 4, 2017 at 2:48 PM, Carter Cheng <cartercheng at gmail.com> wrote:

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