Greetings. :)

[Nathan Yospe]

On Sun, 6 Apr 1997, Chris Gray wrote:

:[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. 

Not from what I remember...

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

Not sure what you mean by "input lines". Does this mean runtime determined
variables in text form? This actually sounds frighteningly close to my
virtual and real functions/classes. The difference, of course, being that
as much as possible of my code is real, and soft becomes real in a short
order of time.

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

It'll be interesting to see his reply.

: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 */

Interesting. Quite interesting. So CreateBoolProp()$ creates a boolean
property... um... which seems to be applied to every object in existance?
What if you have a property list that goes into the thousands? Erm. Hmm.
Still... an interesting system. I guess I should post up my method of
dealing with properties. For the above, I have... well... OK, near as can
get to what you have...

class gender inherits BoolProperty{
@ functions
  bool male(){ return property; }
  bool female(){ return !property; }
  String sex(){ property ? (return "male";) : (return "female";); }
@ data
  bool property;
}

class banana{
  gender bananaSex(); // default const while data member exists with same
                      // name... cannot define as non const.
  void setSex(); // toggle gender     
@ data
  gender bananasex = false;
}

banana.bananasex().male(); // yields false 
banana.setSex();
banana.bananasex().male(); // yields true

And the rest requires an explicit modification to the banana class. Of
course, the modification could be made in the Virtual class, which all
virtual objects inherit, or in the hardcoded Physical, Location, Doorway,
or Universal classes... but that requires a recompile. The idea is,
anything fundamental to the entire universe _should_ require a recompile,
in my formula, because otherwise a) it introduces a violation of
encapsulation that can be made by anyone, and b) it usually indicates
improper design, under my paradigm.

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

Interesting. Not sure how I would equate this. I have things like this: 
location.SendImpulse(Heat(100), Coordinate(0,3,7,9,2,1));
and
target.SendImpulse(Pressure(80, Surface(1,30)), Coordinate(0,0,0,12,1,3));

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

OK, once we have the bucket, a standard, no frills Item, we add a spell to
it. Say the spell is to a particular stone. Say it is a permanent spell,
for simplicity, and that it is in place at startup.

So, first we attatch the spell to the bucket, with a trigger to transmit
weight changes. We have a call to create (or choose) a stone when the
bucket is created.

#ITEMS

> bucket{
N bucket~
// . . . all the other stuff . . .
P MassSpell(mass()) <void massUpdate()>
I stone
}

#PROGRAMS

void bucket:MassSpell(int newMass){
  stone.SetState(mass, newMass);
};

>From this, there is a series of messages passed, that ultimately reaches
the tree. This last impulse schedules an immediate event for the tree to
fall down.

   __    _   __  _   _   ,  ,  , ,  
  /_  / / ) /_  /_) / ) /| /| / /\            First Light of a Nova Dawn
 /   / / \ /_  /_) / \ /-|/ |/ /_/            Final Night of a World Gone
Nathan F. Yospe - University of Hawaii Dept of Physics - yospe at hawaii.edu