[DGD] Delay statements in scripting

[Felix A. Croes]

>   There's one different very simple and fundamental
> action that scripts want to take, and it's harder to
> implement:  delays.  When you want a mobile to look at
> what it's been given, wait a few seconds and give it
> back disdainfully, it's important to wait that few
> seconds.  The problem is that DGD is single-threaded,
> which means that threads of execution need to finish
> *fast* so that the rest of the MUD can get on with
> what it's doing.  A three-second delay loop isn't an
> option, and would halt the rest of the MUD, spoiling
> the effect.  It doesn't work.

Take a look at what LPMOO does: it uses DGD to fully simulate a MOO,
which does indeed have such delays.

Instead of programming in LPC, you write in a scripting language (which
can be identical) which is translated into LPC.  All local variable and
function argument references are replaced with references to some pool
where they can be kept in case of a delay.  Each function is called with
an additional argument, the entry point; each function call and each
delay creates a new entry point just before, and just after the function
call or delay, respentively.  You arrange the code for quickly restarting
at this entry point.  LPMOO puts the whole function within a switch, as
follows:

    int foo(int entry, mixed *variables_and_arguments)
    {
	switch (entry) {
	case 0:
	    /* normal start of the function */
	    ...
	case 1:
	    /* further within */
	    ...
			    case 2:
				/*
				 * still further, several compound statements
				 * deep, switch allows this
				 */
				 ...
	}
    }

MOO code doesn't have a switch (or didn't at the time), so this was the
easiest solution.  With a switch construct in your scripting language of
choice it becomes a little more complex -- more entry points will have
to be generated.

That is the easy part.  Not so easy is the programming environment you
have just created.  Remember that arrays, mappings and light-weight
objects are local to persistent objects, and that each delay can create
local copies of them.  Furthermore, a cooperative multitasking environment
suffers from the usual well-known drawbacks, which will be especially
evident in a tightly integrated system such as DGD's.

Regards,
Dworkin
_________________________________________________________________
List config page:  http://list.imaginary.com/mailman/listinfo/dgd