[MUD-Dev] Re: PDMud thread summary

[Chris Gray]

[Jon A. Lambert:]

[I've left email until quite late, so I could get some work done. So, if
I'm even less coherent than normal, forgive me!]

 >Rare, unless modules can be instanced or otherwise replicated.  I 
 >mentioned that in another post tonight...  I think we can support 
 >both procedural languages and object-oriented languages as mud 
 >languages.  I'd prefer to support an object-oriented mud language, 
 >which might require support multiple instances of modules (at least 
 >any state they contain, not necessarily code)

Why does support for an OO language require multiple instances of the
module for it? Wouldn't all the language state for a given client be
bundled up as part of the client state?

 >>  >Are function calls resolved at compile-time, registration, or run-time?
 >> 
 >> Depends on what you mean by 'resolved'! Calls to visible names within
 >> a module should be resolved at compile time. Calls from one module to
 >> another that are fixed calls (not dependent on run-time data) can be
 >> resolved at registration (module load) time. Calls via pointers that
 >> MUD-code or module code can modify need to be at run-time. The comparative
 >> cost increases in that same sequence.

 >Would a successful compile automatically go ahead and register the 
 >module?   Any concerns here.  I've always thought an automated mud 
 >language source versioning system would be nice.

Not register, no. There is no need to register functions that are
fully resolved at compile time. You only need to register functions that
a module exports or imports when that module is loaded. I view a call
fully determined at compile time to be essentially invisible outside of
that hunk of code. Sort-of like C compilers just emit PC-relative
branches for calls to other routines in the same source file.

 >> Sure, that's fairly standard. The other thing you often want is for the
 >> return instruction to pop/deallocate any local variables as well.
 >
 >Aye.  How about support for static variables and recursion.  We 
 >haven't discussed module level variables (outside of functions).

True. Recursion should fall out of any stack-based system. I solved
the problem of non-local variables by not having any. You can either
have persistent entities in the database (hence referenced by DB-Id),
or you can have local's. It's a very occasionally annoying restriction,
but it does work. That may not work properly with some OO styles,
however - I can't judge that.

--
Don't design inefficiency in - it'll happen in the implementation. - me

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