Greetings. :)

[Chris Gray]

[Nathan Y asks some questions of Chris L, based on Chris's replies to
Michael H's questions (or something like that!). I'm going to jump in
with my replies, which will likely be similar, but different enough,
from Chris L's.]

:This code would be what, interpreted, partial (bytecode) compile, partial
:(bundled pointer) compile, or full (dynaloaded) compiled?

I believe that as much as possible of Chris L's MUD code will execute
interpreted. I don't know the details. My system is similar, but I might
have more native-code help underneath. Think in terms of LPMud efuncs
and simul-efuncs (did I get those right?) At some point, everything really
gets done by native code (efuncs), but is driven at the upper level by
interpreted funcs. The question then becomes one of what level the
changeover happens. i.e. what level of support functions are done at the
native level? For example, I have a fairly complex 'Parse' native code
function that handles input commands and calls out to interpreted code
for specific commands. A difference is that I call it from interpreted
code that is triggered for input lines, whereas I believe LP calls it
automatically, with no possibility of intervention at that level.

:What exactly do your states look like, if you don't mind answering? My
:'states', insomuch as I have them, are themselves compound objects. The
:only other approach I am really familiar with is *shudder* Merc style
:"long state_holder" with the "#define A 1; #define B 2; #define C 4;"
:bit container method... and I'm sure you use nothing like that.

No, nothing like that. I think Chris L. defines properties as belonging
to classes (i.e. each class member will have the property with some
value), and then inherits from that class to give the property to more
objects. Mine is less structured - each 'thing' is just a list of property/
value pairs. If a given property exists on the thing, then its value is
returned on a query. If the property doesn't exist, the ancestor chain
is checked, and if it still isn't found, the database returns a default
value based on the type of the property (my system is strongly typed).
So, you do something like:

    public male CreateBoolProp()$
    public banana CreateThing(nil)$	/* no ancestors */
    banana at male$			/* yields the default 'false' */
    banana at male := true$
    banana at male$			/* now yields 'true' */
    public age CreateIntProp()$
    banana at age$ 			/* yields the default 0 */

:OK, yours bounce too... but after the entire message has been passed, even
:if there is no channel for dealing with the input. I really am surprised
:how many parallels exist here... considering that we are running radically
:different systems, and the supposedly similar systems to my own have no
:parallels whatsoever.

Chris L's system is quite flexible there. Maybe he'll repost some of
the previous examples (hmm - didn't you already see some?). In mine, I
can sort of fake it, but its a bit more explicit:

    public someTrigger CreateActionProp()$
    public someObject CreateThing(someParent)$
    public proc doAction()void:
	<code to execute>
    corp;
    someObject at someTrigger := doAction$
    inside some code that wants to execute 'someTrigger' on an arbitrary
	object in variable 'theObject':

	    thing theObject;
	    action theAction;
	    ...
	    theAction := theObject at someTrigger; /* database lookup */
	    if theAction ~= nil then		/* not the default 'nil' */
		/* this object can respond to the trigger */
		call(theAction, void)();
	    else
		/* this object cannot respond to the trigger */
		<some kind of default activity>
	    fi;

:Now, to the crystal tree...
:
:There is a bucket with a sympathetic spell to something atop the tree,
:correct? And the tree can only support so much weight, so adding water to
:the bucket eventually overloads the tree and the tree crashes down. (nice
:liquid problem, that... or fluid, at least... crystal units begin to
:approximate sand) Bubba is a physical object, that exerts mass reaction to
:gravity... in other words, he keeps track of the theoretically static
:value of his mass. He has in his possesion an object that will be asked to
:increase mass by the bucket, thanks to the spell on the bucket. When the
:object agrees to increase mass, this is passed as a dynamic impulse to
:bubba, who passes it in turn to his location... a tree that cares about
:such state changes, and doesn't like them one bit. It collapses. Unless I
:missed something here, this was never a problem with my impulse passing
:method, as the only way for the bucket to increase the sympathetic objects
:mass was by transmitting an impulse to it, and impulses always go merrily
:down the line.

This sounds interesting. Can we see a bit more detail here?

--
Chris Gray   cg at ami-cg.GraySage.Edmonton.AB.CA