MUD-Dev
mailing list archive
[ Other Periods
| Other mailing lists
| Search
]
Date:
[ Previous
| Next
]
Thread:
[ Previous
| Next
]
Index:
[ Author
| Date
| Thread
]
[MUD-Dev] Re: PDMud (was Re: Bruce Sterling on Virtual Community goals)
[Hal Black:]
>One thing I'd really like to see, is have the modules made from VM code
>completely interchangable with modules made from native code. That way,
>it would be a lot easier to replace VM code bit-by-bit with native code if
>you need to do so for performance purposes. This would be especially nice
>if, say, the driver part was in C++, and there was a C++ to VM compiler.
>Then, you could swap stuff in and out of VM mode as desired for profiling,
>debugging, security, and so forth.
As I mentioned in an earlier note, problems arise more from run-time
library or support environment than from strict language issues. In this
particular instance, please note that C++ is a very large language - building
a compiler for it is man-years worth of work. There are some available
parsers out there, but then the problem of licensing can come up.
An in-MUD language will typically have language elements that are added
to make in-MUD programming easier. Those won't exist in external languages,
and so that stuff would have to be translated into function calls,
possibly quite a lot of ugly ones. As an example, the statement:
player@hits := player@hits - weapon@hits;
in my system, would have to be translated into something like:
PutProperty(player, GetProperty(player, hits) -
GetProperty(weapon, hits));
assuming you have simple values usable as database identififers.
Keeping the in-MUD language(s) for higher-level world/quest/NPC stuff and
the native compiled language(s) for lower-level things is probably a
good idea.
--
Chris Gray cg#ami-cg,GraySage.Edmonton.AB.CA
[ Other Periods
| Other mailing lists
| Search
]