MUDs in Perl

Shevek shevek at
Tue May 20 12:06:15 BST 2008

On Mon, 2008-04-28 at 10:22 +0100, Kake L Pugh wrote:
> On Mon 28 Apr 2008, Simon Wistow <simon at> wrote:
> > Shevek, occasionally of this parish, wrote an LPC driver in Perl for 
> > Anarres
> > 
> >
> Hm, I was sure I'd mentioned this in my original mail but it looks
> like I took that part out.  Anyway: Anarres::Mud::Driver is
> unmaintained, doesn't compile on my laptop (which is where I want to
> run it, at least at first), and only gets me LPC anyway, which I don't
> really want for various reasons.
> (I think the answer to my question is probably "you can't do that", and
> "nobody cares about MUDs any more", but I thought it was worth asking
> on the offchance.)


I was pointed at this thread, and then I forgot, so I will give the
official answer as I see it. I do actually have working and reliable
solution to this question, which might very much interest people.

=== The Front End ===

You can parse (frontend) C, LPC, whatever in Perl. AMD contains a full
frontend for turning LPC into some form of intermediate language. What
we learn from that frontend is this:

Parse::Lex (or whatever it was) and Parse::Yapp is horrifically and
unrealistically slow. If I replace the lexer with a hand-written Perl
lexer, it gets a bit faster, but basically, I did a lot of work to
integrate actual bison and flex with Perl in a thread-safe or
multiple-instance-safe manner. At this point, you get a reasonable
performance (about 3,000 lines/sec in the frontend) but the lack of an
automatic parse-tree builder and the difficulty of writing any
significant amount of code in XS make it essentially unmaintainable.

=== The Middle End ===

What you can do in the middle end is limited by the ability to build a
sensible parse tree in the front end, and by the performance of Perl.

=== The Back End ===

You can't actually generate general purpose code for the Perl VM. I
tried using B::, I tried generating Perl which I eval'd, I tried several
solutions. Basically, it can't be done. If you're not writing Perl,
don't use the Perl VM.

=== The Actual Solution ===

It's not released yet, but I have a nearly fully working, very high
performance LPC driver, and by fast, I mean it compiles so fast I
haven't even measured it yet, and runtime is in the order of optimized C
from gcc, which is between 100 and 1,000 times as fast as any existing
LPC driver, and naturally knocks the crap out of Perl for speed and
efficiency. It's also truly threaded and very easy to integrate with.
The core codebase is about 8,500 lines, and the LPC standard library is
an additional 12,000 lines. It will eventually support Anarres, MudOS,
DGD and CD style muds, I'm actually going for full turnkey compatibility
with all of the above.

The system is written in pure Java, it actually compiles LPC down to JVM
classes, which it loads on the fly, in exactly the same manner as a
traditional LP MUD, and gives all the same semantics. However, you can
also write classes in real Java and load them, so it's fairly easy
(given system level access) to write an LPC class which uses JDBC,
Jetty, Mina, etc.

The web site will be at and if
you're very lucky, I'll have a page put up there by the time you get
this far down this mail. In the meantime, I have a subversion
repository. If you're interested, please talk to me offlist.

=== The Future ===

Well, given a codebase like this where it's easy for users to write,
load and unload code, and it's all controlled using a sane and sensible
stack security model, a lot of things become possible which simply can't
happen in any other codebase. You can edit over the built in web server,
store code in SQL or via VFS, or just about anything you please. I'm
very interested in hearing from people with ideas for this code.

In fact, I've written so many compilers targeted at the JVM now that I'm
tempted to write a Perl one. This is partly why you haven't heard from
me on this list for a while... although I do need to post about an
upcoming event!


More information about the mailing list