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

[Jon Leonard]

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.

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?

> This sounds like an interesting project.  Something where you could 
> limit the scope quite nicely to a drop in VM component with clearly 
> delineated boundaries.   

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.

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?

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

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.

> I'm game.  :)  

Cool.

Jon Leonard