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

[Jon A. Lambert]

On 19 Oct 98, Jon Leonard wrote:
> On Mon, Oct 19, 1998 at 10:22:12PM +0000, Jon A. Lambert wrote:
> > On 19 Oct 98, Jon Leonard wrote:
> > > On Mon, Oct 19, 1998 at 05:37:55PM -0600, Chris Gray wrote:
> 
> [in-MUD languages for a flexible MUD server]
> 
> > > I don't think a single monolithic server would be flexible enough for
> > > what most of us are interested in.   I'd build a mix and match collection
> > > of components for things like internal language.  Some successful MUDs
> > > don't have internal languages at all, and that's a model we should support
> > > too.
> > 
> > You're right.  I think a better way to approach an extensible 
> > (generic?) internal mud language is to design the VM first.  More 
> > particularly a byte-code assembler.  From there, anyone could create 
> > a compiler for their favorite language du jour.   If you prefer 
> > strong typing over weak typing, the compiler would simply ignore or 
> > not generate opcodes that deal with type promotions/conversions. 
> 
> I don't think building a fully featured VM is feasable right away,
> especially if by fully featured we mean every buzzword we can think of.
> Designing a secure, efficient, garbage collected, threaded, distributed,
> capability-based, properly tail recursive (etc.) virtual machine is
> (at least) a serious research project.  It also wouldn't be nearly as
> easy to understand as simple interpreter that fit the same interface.
>

I don't see why an interpreter would not look vitually identical to a 
VM that processes bytecode.  An interpreter would normally use 
lazy evaluation and so could the bytecode generator.  That is code 
generation or execution would occur at the same points in the 
execution of the interpreter/code generator.  Possibly just a 
flag could control what output is desired.  State information saved 
for interpretation (labels) would just as easily be used in 
generating bytecode.

Secondly a standard bytecode gives you a common target for
any desired language compiler.  C. Gray's horrendous case/esac 
(hehe) structures or my lovely if/endif repeat/until proclivities. 
;)

It also gives you a common source for any native code generation.  
Niklas Elmqvist's dynamically loading native code segments being an 
excellent target for a backend bytecode assembler.

> That said, I think some sort of byte-code machine makes a lot of sense
> as an option.  Which buzzwords do we want to start with?
>

General design:

Functionally cohesion and loosely coupled.  Easy to say, but we don't 
want spaghetti and plethora of global variables.  We need a style 
nazi...(I'm certain we have different styles).  I don't like 
hungarian notation myself, but something more comprehensible and 
followable.

Threadsafe - multiple instances of the executor/VM should be able to
run concurrently.  All stacks and psuedo-registers would be 
localized.  Question(?) need to ensure mud data/objects are locked
from VMs, and more importantly, what might be a single-threaded
server that it is plugged into.  This is easily accomplished with a 
threadsafe pointer class in C++, and any number of ways in C.

Stack-based or psuedo-register based?

Details:

Primitive data types to be represented.
Complex data types (object).
Control structures.
Looping structures.
Subroutines/procedures/functions.
Label generation.
Symbolic storage.
Variable storage.
Type conversions/promotions.
Native routines call and return format/native symbol table.
Sub progam/module call and return protocol.
Exception handling/trapping
Arithmetic processor.
Booleans/conditionals.
Operator precedence.

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.
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.  
   
> Left to my own devices, I'd implement these calls as C functions.

Agreed.  Most languages can handle C call format. (Java, C++, C and 
Pascal).

> Each module would have a structure listing the names of the functions
> it exported and function pointers.  The structure might include stuff
> about calling conventions, a documentation string, etc.  In my current
> server, all functions take and return linked lists of arguments/results,
> but that's not necessarily the best choice.

Aye.  A linked list or array of pointers sounds good.  Would this 
imply no argument type-checking, or is this something better left to
the language compiler to enforce?
 
> We might need to have (compile time option?) more than one calling
> convention, and certain modules might use backdoor entry points
> into other modules for efficiency.

A needless complication at this point, perhaps? 

Just a few thoughts...
--
--/*\ Jon A. Lambert - TychoMUD     Internet:jlsysinc at ix.netcom.com /*\--
--/*\ Mud Server Developer's Page <http://www.netcom.com/~jlsysinc> /*\--
--/*\   "Everything that deceives may be said to enchant" - Plato   /*\--