[MUD-Dev] Languages

[Miroslav Silovic]

> [Miro:]
> 
> :Neat. So what's the type of nil? :) It's obviously not a list. How do
> :you declare it? And why is it better than completely generic types (if
> :you still have to check whether it's a list or nil in every list
> :operation, you could just as well check for all other types)?
> 
> 'nil' is a language construct. It is defined to be equal to no pointer,
> and to be such that any pointer can be compared for equality against it,
> and such that it can be assigned to any pointer type. I'm not sure where
> the concept first originated, but I think AlgolW had one (spelled 'null'),
> and I know Algol68 has one. Internally to the parser, it has type
> <NIL-TYPE>, and all type-checking code knows about it.

Ah, just as I expected... But if you have type checking, you could just
as well replace it with true type dispatch and use dynamic types
instead? :)

(note that if MUD is hard to debug because of no debug support, dynamic
typing is not the one to blame. Stack trace is your friend in all
dynamic languages, starting with LISP - and it's something that is
far harder to program in a static language, although not at all
impossible).

> To clarify a bit about text output. In the MUD code, you just do something
> like	Print("This is some text to send to the client.\n");	and the
> formatting of it for the client window will be handled by the system.
> There was some earlier discussion on this, relating to indentation.

Ah, this is actually neat for most purposes. The problem we deal with
in Cold was the fact that often a piece of hypertext is dispatched
to, say, 200 clients (I've actually been in a scene on a MUSH with
200 players in the same room. I've /ran/ parts of that scene. Don't
ask. You really have to /feel/ it for the full experience. :) ).
The text also had to propagate (as opposed to /events/, which are
far easier to deal with).

To illustrate:

	message originator -> room1  -> player, player, player
			       |
			       V (message gets modified with prefix)
			      room2  -> player, player, player,
			     /		telepathic robot
			    mud TV		|
			    |			V(modification again)
			    V		     player
			observers

As you can see, the propagation chain gets VERY complicated. The most
natural (whatever it means - I'm far for claiming that this is the only
way) is to pass the message through object-to-object method calls.
But this requires hypertext 'somthing' to be tangible, propagatable
object. This is the problem that had to be solved. :)

Note that emotes are plain text, and it had to mesh well with messages.

> :Err, no, if you said it was safe, I believe you. This is independant
> :statement: I don't like thinking about implementation when designing
> :the language. It can destroy the design (the problem is called
> :'premature optimization'). I'm not saying it did, in your case...
> :How about starting serious thread on language design, with concrete
> :language proposals?
> 
> OK, thanks. We could try to get a discussion going on MUD languages, but
> I'll bet it would be hard to avoid getting trapped into religious issues!
> Perhaps the best way to start would be if those with existing languages
> could point out where we can find documentation on those languages. I'm
> assuming I'm not the only one that's far enough into the cycle to have
> such documentation? I just looked, and the two files that are my main
> programming docs (not including the builtins) amount to 4600 lines. Too
> much to put on this list, but I can make them available for ftp if anyone
> wants to get into that much detail.

Principal languages that make great reading:

http://www.dcs.napier.ac.uk/course-notes/sml/manual.html

This is ML specification. ML is very spartan, and is meant as a testing
ground for language design concepts. There are some good libraries,
so you can still do real work with it. There are both free and commercial
compilers. It's statically typed, and *very* clean. For instance, there
is no notion of 'pointer', and you don't actually need it.

http://www-swiss.ai.mit.edu/scheme-home.html

This is Scheme reference. Scheme is deliberately kept small, and its
design phylosophy is 'Most kick per feature'. This means that there
are indeed very few features (there is a semi-standard Scheme library,
which fixes this) but with them, you can do incredibly powerful stuff
(you can implement different object systems, and even a meta-object
protocol. You can implement threads, exceptions, co-routines. Lazy
evaluation is a built-in feature, allowing you to define infinite
datastructures. And so on). You can use it both for exploration and
for serious programming. There are free and commercial compilers,
some of which produce very efficient code. Oh, it's dynamically typed,
but some compilers use type inference to check types at compile
time for you (i.e. they figure types of the vars from the expressions 
they're used in - as it should be done. :) )
The thing to study with Scheme are macros, as Scheme as LISP macros
are probably more powerful than in any other language (the cost
is syntax, as those languages had to be able to parse themselves).

http://www.harlequin.com/books/HyperSpec/

This is specification of ANSI Common LISP. Unlike the two above, this
is fully featured language, with library standard (it's part of the
language, actually. So are basic debugging facility).
CL is both statically and dynamically typed - programmer gets to choose.
It has object system, tons of builtin datatypes (it uses *huge*
hierarchy of types. For instance, it has arrays with unspecified
number of dimensions, and unspecified elements. Or two-dimensional
arrays of complex numbers. Or two dimensional 5x16 arrays of vectors
of uncpecified type. You can even define all objects that satisfy
some property to be a new type, and you can give a property through
function that checks for it.). And so on and on and on.

The text on the URL above is 15 megs, but its well worth at least
browsing, as it contains large number of new concepts you'd never think
of otherwise. For instance, function calls that look like
(function arg arg arg :keyword arg :keyword arg :keyword arg)
(and you can specify defaults for arguments that don't appear in the
call, and you can even check whether they appeared).

As for the MUD languages, the Cold manual is at

http://ice.cold.org:1180/bin/help?node=$help_coldc

MOO manuals should be easy to find and is a canon example of the
server that is secure enough to allow user-level programming (but
is too slow for it. ;) )

And reading up on C, C++ and Java goes without saying. :)

	Miro