<!-- MHonArc v2.4.4 -->
<!--X-Subject: [MUD-Dev] Re: Bruce Sterling on Virtual Community goals -->
<!--X-From-R13: "Xba O. Znzoreg" <wyflfvapNvk.argpbz.pbz> -->
<!--X-Date: Tue, 20 Oct 1998 20:10:36 -0700 -->
<!--X-Message-Id: 199810210306.WAA26802@dfw-ix5.ix.netcom.com -->
<!--X-Content-Type: text/plain -->
<!--X-Reference: 199810200221.VAA03218@dfw-ix6.ix.netcom.com -->
<!--X-Reference: 19981019212302.A7642#divcom,slimy.com -->
<!--X-Head-End-->
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<html>
<head>
<title>MUD-Dev message, [MUD-Dev] Re: Bruce Sterling on Virtual Community goals</title>
<!-- meta name="robots" content="noindex,nofollow" -->
<link rev="made" href="mailto:jlsysinc#ix,netcom.com">
</head>
<body background="/backgrounds/paperback.gif" bgcolor="#ffffff"
text="#000000" link="#0000FF" alink="#FF0000" vlink="#006000">
<font size="+4" color="#804040">
<strong><em>MUD-Dev<br>mailing list archive</em></strong>
</font>
<br>
[ <a href="../">Other Periods</a>
| <a href="../../">Other mailing lists</a>
| <a href="/search.php3">Search</a>
]
<br clear=all><hr>
<!--X-Body-Begin-->
<!--X-User-Header-->
<!--X-User-Header-End-->
<!--X-TopPNI-->
Date:
[ <a href="msg00284.html">Previous</a>
| <a href="msg00286.html">Next</a>
]
Thread:
[ <a href="msg00289.html">Previous</a>
| <a href="msg00288.html">Next</a>
]
Index:
[ <A HREF="author.html#00285">Author</A>
| <A HREF="#00285">Date</A>
| <A HREF="thread.html#00285">Thread</A>
]
<!--X-TopPNI-End-->
<!--X-MsgBody-->
<!--X-Subject-Header-Begin-->
<H1>[MUD-Dev] Re: Bruce Sterling on Virtual Community goals</H1>
<HR>
<!--X-Subject-Header-End-->
<!--X-Head-of-Message-->
<UL>
<LI><em>To</em>: <A HREF="mailto:mud-dev#kanga,nu">mud-dev#kanga,nu</A></LI>
<LI><em>Subject</em>: [MUD-Dev] Re: Bruce Sterling on Virtual Community goals</LI>
<LI><em>From</em>: "Jon A. Lambert" <<A HREF="mailto:jlsysinc#ix,netcom.com">jlsysinc#ix,netcom.com</A>></LI>
<LI><em>Date</em>: Tue, 20 Oct 1998 23:07:16 -5</LI>
<LI><em>Reply-To</em>: <A HREF="mailto:mud-dev#kanga,nu">mud-dev#kanga,nu</A></LI>
</UL>
<!--X-Head-of-Message-End-->
<!--X-Head-Body-Sep-Begin-->
<HR>
<!--X-Head-Body-Sep-End-->
<!--X-Body-of-Message-->
<PRE>
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#ix,netcom.com /*\--
--/*\ Mud Server Developer's Page <<A HREF="http://www.netcom.com/~jlsysinc">http://www.netcom.com/~jlsysinc</A>> /*\--
--/*\ "Everything that deceives may be said to enchant" - Plato /*\--
</PRE>
<!--X-Body-of-Message-End-->
<!--X-MsgBody-End-->
<!--X-Follow-Ups-->
<HR>
<ul compact><li><strong>Follow-Ups</strong>:
<ul>
<li><strong><A NAME="00288" HREF="msg00288.html">[MUD-Dev] Re: Bruce Sterling on Virtual Community goals</A></strong>
<ul compact><li><em>From:</em> Marc Hernandez <marc#jb,com></li></ul>
</UL></LI></UL>
<!--X-Follow-Ups-End-->
<!--X-References-->
<UL><LI><STRONG>References</STRONG>:
<UL>
<LI><STRONG><A NAME="00257" HREF="msg00257.html">[MUD-Dev] Re: Bruce Sterling on Virtual Community goals</A></STRONG>
<UL><LI><EM>From:</EM> "Jon A. Lambert" <jlsysinc#ix,netcom.com></LI></UL></LI>
<LI><STRONG><A NAME="00261" HREF="msg00261.html">[MUD-Dev] Re: Bruce Sterling on Virtual Community goals</A></STRONG>
<UL><LI><EM>From:</EM> Jon Leonard <jleonard#divcom,slimy.com></LI></UL></LI>
</UL></LI></UL>
<!--X-References-End-->
<!--X-BotPNI-->
<UL>
<LI>Prev by Date:
<STRONG><A HREF="msg00284.html">[MUD-Dev] Re: Bruce Sterling on Virtual Community goals</A></STRONG>
</LI>
<LI>Next by Date:
<STRONG><A HREF="msg00286.html">[MUD-Dev] Re: Bruce Sterling on Virtual Community goals</A></STRONG>
</LI>
<LI>Prev by thread:
<STRONG><A HREF="msg00289.html">[MUD-Dev] Re: Bruce Sterling on Virtual Community goals</A></STRONG>
</LI>
<LI>Next by thread:
<STRONG><A HREF="msg00288.html">[MUD-Dev] Re: Bruce Sterling on Virtual Community goals</A></STRONG>
</LI>
<LI>Index(es):
<UL>
<LI><A HREF="index.html#00285"><STRONG>Date</STRONG></A></LI>
<LI><A HREF="thread.html#00285"><STRONG>Thread</STRONG></A></LI>
</UL>
</LI>
</UL>
<!--X-BotPNI-End-->
<!--X-User-Footer-->
<!--X-User-Footer-End-->
<ul><li>Thread context:
<BLOCKQUOTE><UL>
<LI><STRONG>[MUD-Dev] Re: Bruce Sterling on Virtual Community goals</STRONG>, <EM>(continued)</EM>
<ul compact>
<ul compact>
<ul compact>
<ul compact>
<ul compact>
<ul compact>
<LI><strong><A NAME="00280" HREF="msg00280.html">[MUD-Dev] Re: Bruce Sterling on Virtual Community goals</A></strong>,
Joel Kelso <a href="mailto:joel#ee,uwa.edu.au">joel#ee,uwa.edu.au</a>, Wed 21 Oct 1998, 01:30 GMT
<UL>
<LI><strong><A NAME="00284" HREF="msg00284.html">[MUD-Dev] Re: Bruce Sterling on Virtual Community goals</A></strong>,
Marc Hernandez <a href="mailto:marc#jb,com">marc#jb,com</a>, Wed 21 Oct 1998, 03:09 GMT
<UL>
<LI><strong><A NAME="00328" HREF="msg00328.html">[MUD-Dev] Re: Bruce Sterling on Virtual Community goals</A></strong>,
J C Lawrence <a href="mailto:claw#under,engr.sgi.com">claw#under,engr.sgi.com</a>, Thu 22 Oct 1998, 01:30 GMT
</LI>
</UL>
</LI>
<LI><strong><A NAME="00289" HREF="msg00289.html">[MUD-Dev] Re: Bruce Sterling on Virtual Community goals</A></strong>,
Jon A. Lambert <a href="mailto:jlsysinc#ix,netcom.com">jlsysinc#ix,netcom.com</a>, Wed 21 Oct 1998, 04:53 GMT
</LI>
</UL>
</LI>
</ul>
<LI><strong><A NAME="00285" HREF="msg00285.html">[MUD-Dev] Re: Bruce Sterling on Virtual Community goals</A></strong>,
Jon A. Lambert <a href="mailto:jlsysinc#ix,netcom.com">jlsysinc#ix,netcom.com</a>, Wed 21 Oct 1998, 03:10 GMT
<UL>
<LI><strong><A NAME="00288" HREF="msg00288.html">[MUD-Dev] Re: Bruce Sterling on Virtual Community goals</A></strong>,
Marc Hernandez <a href="mailto:marc#jb,com">marc#jb,com</a>, Wed 21 Oct 1998, 04:50 GMT
<UL>
<LI><strong><A NAME="00324" HREF="msg00324.html">[MUD-Dev] Re: Bruce Sterling on Virtual Community goals</A></strong>,
Jon A. Lambert <a href="mailto:jlsysinc#ix,netcom.com">jlsysinc#ix,netcom.com</a>, Thu 22 Oct 1998, 00:32 GMT
</LI>
</UL>
</LI>
</UL>
</LI>
</ul>
</ul>
</ul>
</ul>
<LI><strong><A NAME="00263" HREF="msg00263.html">[MUD-Dev] Re: Bruce Sterling on Virtual Community goals</A></strong>,
Chris Gray <a href="mailto:cg#ami-cg,GraySage.Edmonton.AB.CA">cg#ami-cg,GraySage.Edmonton.AB.CA</a>, Tue 20 Oct 1998, 04:42 GMT
<UL>
<LI><strong><A NAME="00264" HREF="msg00264.html">[MUD-Dev] Re: Bruce Sterling on Virtual Community goals</A></strong>,
J C Lawrence <a href="mailto:claw#kanga,nu">claw#kanga,nu</a>, Tue 20 Oct 1998, 04:45 GMT
</LI>
</UL>
</LI>
</ul>
</LI>
</UL></BLOCKQUOTE>
</ul>
<hr>
<center>
[ <a href="../">Other Periods</a>
| <a href="../../">Other mailing lists</a>
| <a href="/search.php3">Search</a>
]
</center>
<hr>
</body>
</html>
