26 Feb, 2008, Silenus wrote in the 1st comment:
Votes: 0
Hi everyone,

I am in the process of writing my own mud server in a similar vein to an lpmud server and was curious what sorts of features people would be most interested in in a project like this. This project started initially as an attempt to construct a variant of LPC for the use of developing muds a bit more succinctly but has then morphed into an attempt to get some next-gen type features into such a platform.

The system will be prototyped in java (unless someone has a better suggestion) and consist of the, like the standard lp design, four parts 1) a language compiler 2) a virtual machine 3) OS level runtime features 4) libraries for various basic builtin commands.

Some desirable features for me would be- garbage collection, persistence, concurrency support via green threads, built-in security distributed features in the VM. The language will most likely be modelled loosely around Lisp/Scheme or something like Haskell/Erlang.

This is primarily a learning project for me. I am hoping by doing it to come to grips with some of the issues in compiler design and implementation and the lambda calculi and language theory. So if there are any gross misunderstandings please forgive me.

Thanks in advance,

Silenus.
26 Feb, 2008, David Haley wrote in the 2nd comment:
Votes: 0
If you're aiming to talk about the lambda calculus, language theory and compiler design/implementation, you might be in a not-quite-right place. :wink:

I think you should separate the two problems you are trying to tackle: (1) writing a MUD server, and (2) designing a language. The problems are for the most part independent, and while there will be some degree of feedback (i.e., it's not just "a language", it's a language to write MUDs in) I think it would be confusing to think about the two separately.

I think your list (GC, persistence, concurrency, security) is a good one. I would add the following (that you probably already know about given your choice of languages to model): functions as first-class values, strong usage of closures/upvalues, some kind of object system (be it class- or prototype-based).

Since you're doing this as a learning project, concerns like "why?" are not really relevant. Nonetheless I would suggest thinking about what it is that languages that you know do not provide, and how you are going to fix that. In other words, imagine somebody asked you: I can embed Lisp/Scheme/etc., or I can use your language – why should I use your language?

Also, I'm not sure that Lisp/Scheme or Haskell/Erlang are necessarily the best choices for a MUD language, but I'm not sure if I could really back that up beyond preference.
27 Feb, 2008, shasarak wrote in the 3rd comment:
Votes: 0
You might find this thread over at TMC interesting:

http://www.mudconnect.com/discuss/discus...
27 Feb, 2008, Silenus wrote in the 4th comment:
Votes: 0
Thank you for the input. You might be correct in that the language design issue and mud server design issue are mostly independent. However the problem for me is that the server VM design can be greatly impacted by the choice of the language used in the front end. I.e. if you implement LISP/Scheme would you want something SECD like instead of JVM/.NET like stack machine? If you had a Prolog like language, it might be best to have something that looked somewhat like the old WAM design and so on.

So my process so far is to collect a feature list first and then try to fit all the features including the language design under one umbrella. I suspect for the most part my language design might not be that new and just borrow features from existing languages like LISP(which I guess was originally designed as an intermediate language).

I am also curious David why you feel that the functional programming language paradigm may not be appropriate for muds. I am right now not locked into this choice but it seems to me from a theoretical standpoint to be the most promising. i.e. it should be relatively easier to port in new developments in language theory into a functional language since alot of the work is done in lambda calculus and logic.
11 Apr, 2008, David Haley wrote in the 5th comment:
Votes: 0
Sorry for the uber-late response. Not sure if this is still relevant, but . . .

In my experience, functional languages tend to not be very good at handling very state-heavy applications like servers that modify state all over the place based on user input. If it were just serving pages, that'd be one thing, but a MUD is doing all kinds of other stuff.

It's true that functional languages tend to be good at the more recent developments of the field, but then again, so are most high-level languages.

Finally, just because the lambda calculus or logic programming etc. are easy in a given language doesn't mean the whole system should be written in that language. Perhaps it makes sense to write the core in one language, and have something like an inference engine written in a different language. This is a fairly common approach, and is sort of the point of embedding higher-level languages in the first place. :wink:
11 Apr, 2008, Silenus wrote in the 6th comment:
Votes: 0
Strange coincidence. Both my mud server design threads after at least a month on inactivity were revived on the same day :P. Actually I have reached similar conclusions after some thought- and have decided to go with a more stateful design for the language though it will still be if possible as close as possible to LISP/Scheme.
0.0/6