LambdaMOO

The whole environment was networked (naturally) and persistent. It was like a giant Smalltalk image shared by everyone; or a networked Emacs with co-operative multitasking.

Because of this, library functions could be written by one person and then used by everyone. There were some very nice ones that came with LambdaCore, and more included with the various derivative Cores that most latter-day MOOs used. Like in Emacs, library functions and interactive commands existed in the same namespace and were distinguished by a special flag (although admittedly I recall it was somewhat tricky to write one ‘verb’ which could be used as both²).

The most useful libraries of functions were ‘corified’ i.e. integrated into the core database (by setting a property on the root object of the database) which gave them a convenient global name. If you wanted to use a library outside this set (though you hardly needed to in my experience, since most admins had configured an ample variety) you could set a property on your own object containing the ID of the object holding the library functions, and then you could access it in a convenient similar manner.

It was also possible for system administrators to patch the core functions of the server (written in C) with replacements written in MOO code.

Since the server had no hash table or other dictionary type built in, you had to use association lists. Here’s an example of a library function (called $list_utils:assoc) which looks up a key in an alist and returns the {key, value} pair containing it.

1: "assoc(target,list[,index]) returns the first element of `list' whose own index-th element is target.  Index defaults to 1.";
2: "returns {} if no such element is found";
3: {target, thelist, ?indx = 1} = args;
4: for t in (thelist)
5:   if ((typeof(t) == LIST) && `t[indx] == target ! E_RANGE => 0')
6:     return t;
7:   endif
8: endfor
9: return {};

Lines 1 and 2 comprise the docstring, available online interactively at any time by just typing help $list_utils:assoc. Line 3 is a ‘spread assignment’ in modern parlance, which extracts named arguments from the argument list passed to the function. (Notice how it’s possible to have an optional component in a spread assignment.)

Line 5 contains a bit of a trick. Lists in MOO were 1-indexed and there was no boolean type, 0 being the canonical false value.³ After checking that the current item in the association list is actually a sublist, it looks at the desired index in the sublist (by default 1 i.e. the first element) and checks if it’s the desired key. The strange backtick and exclamation mark syntax is a try/except expression — i.e. if looking for the key returns E_RANGE (a list index out of range error), evaluate to false.

Apart from having no dictionary type available, there was also no way to put control characters in strings, including newlines. Multi-line strings were actually lists of strings.

To prevent excessive resource use, every program could only execute a certain number of VM instructions before it was killed. You could get around that by calling the sleep function which reset your tick counter; there was, of course, a library function that would check if you were running out of ticks and call it for you if you were. Every user had a limited quota for their objects, which could either be based on counting the objects themselves or estimating their actual size in bytes.

Security was handled in an interesting way: in Unix terms, every interactive function was setuid to the person who wrote it. So if you didn’t want people running weird code on your account, don’t write that code! (You could make functions ‘private’ for your own use by calling a function that gave you an inspectable stack trace and making sure your callers were trusted.)

The object database was prototype-based, with a few bits and bobs to make it more like a class-based system. Only objects with a +f flag could be cloned; those with this flag set were then usually considered ‘generic’ examples of their class. For instance, if I made a prop for the virtual environment called ‘generic kettle’, I would then set +f, clone it and create ‘dpk’s kettle’, and anyone else could make their own kettle in the same way.

• Intrinsically networked, collaborative, and social
• A persistent object database as storage for all data and code
• Diverse range of functions available in the standard library of most database cores
• Encouraged code-sharing through a global object naming and numbering system
• Some good tools for reflection and code inspection

• Limited set of data types (integer, float, string, list, object-reference)
• Programming language somewhat underpowered (e.g. no lambdas)
• Object creation expensive, especially given quota restrictions
• Only suitable for creating line-oriented applications