[MUD-Dev] Re: Bruce Sterling on Virtual Community goals

[Marc Hernandez]

On Tue, 20 Oct 1998, Jon A. Lambert wrote:

}Stack-based or psuedo-register based?

	Does a psuedo register system create any real benefit?  They are
still implemented as memory locations AND have the additional benefit of
having to be saved and loaded (unless there is some nice benefit I didnt
think of (which is very possible (like reading lisp?))).

}Details:

}Primitive data types to be represented.
}Complex data types (object).

	Why?

}Control structures.
}Looping structures.
}Subroutines/procedures/functions.
}Label generation.

	hmmm.  Isnt this only for the assemblers benefit?  Why not skip to
memory locations?

}Symbolic storage.
}Variable storage.
}Type conversions/promotions.

	Isnt this basically a compile time issue? 

}Native routines call and return format/native symbol table.
}Sub progam/module call and return protocol.
}Exception handling/trapping
}Arithmetic processor.
}Booleans/conditionals.

	necessary for looping/control.  Doesnt have to be true booleans.

}Operator precedence.

	operator precedence is taken care of by the compiler (else
expression evaluators would be very easy to right :-) ).

}Perhaps some of the above are better left to the compiler module 
}designer.

}> It's not yet clear what the boundaries should be, either.
}> 
}> I'm thinking that other modules should present entities (like sockets)
}> and functions that operate on them (like write string to).  From the
}> object-oriented viewpoint, the operations are methods on these entites.
}I assume you mean that result of compilation would be a component.

	Is this necessary?  It would be nice to have a binding to C but
beyond that should be left up to the compiler.  The VM would know nothing
about this.  

}That component exposes itself to the executor/VM.  How does 
}interpretation fit in this model?  How can you expose an interface
}to a module before it's interpretation?  This implies a compilation 
}to bytecode/pseudo code, don't it?
} 
}> It looks like any such system needs to have functions (and callbacks),
}> and these are functions of more than one argument.  Is there anything
}> else that needs to go in the interface layer?  Unique IDs?
}
}Unique ID's are crucial to object manipulation.  For instance the 
}interface to a ROM drop in might be object/room vnums.  Those objects 
}would have no methods of course.  I would think the specifications 
}for "object" would be a custom interface.  A generic way to descibe 
}an object to the VM would be needed.  

	Such as leave it as 'memory' and let the language impose its own
structure to it.  (like the fact that there are no 'signed' integers to
the processor.  Just sets of bits with operations on them.  We impose the
fact that _these_ four bytes are a signed integer and thus we use
SignedAdd etc).

Marc Hernandez		marc at eisoftware.com
Programmer		www.eisoftware.com