[MUD-Dev] Language design

[Chris Gray]

[Chris L:]
:>I have a hard time thinking of any disadvantages of using a more
:>general purpose language, combined with a number of built-in
:>functions to efficiently support the things that are used a lot by
:>the expected code.
:
:Agreed.
:
:My general approach is to do a general purpose language, and to then
:add in data-specific features to customise it to the sorts of data I
:expect the language to be used for.  Thus, my internal language has
:many simple ways to represent and process lists of various types, as I
:see that as a common data manipulation for a MUD.

I had another thought about this after the one Chris L is responding to.
That is that you need to plan ahead for your language. You don't want
to just tack one on to an existing system. I did that once with a
debugger, and, well, it showed. Another example I've looked at a bit
lately is the language inside TinyFugue. It's ugly! The problem comes
from not planning on having a language in the system from day one.
You end up with the syntactic things that the programming language
wants not being the normal way you do things, and so you have to put
in lots of backslashes, braces, different kinds of quote marks, etc.
Like in shell programming. I like the approach I did in ToyMUD - if
the input line starts with a period, then you switch, right there, to
the tokenization and syntax rules of the system programming language,
and you stay that way until the program entity is complete or aborted.
Feel free to have escapes back to "normal mud commands", but don't
try to mix the two modes in the same tokenization rules.

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