[MUD-Dev] Clients

Jon Leonard jleonard at divcom.umop-ap.com
Tue Feb 17 21:48:12 CET 1998


On Tue, Feb 17, 1998 at 08:40:39PM +0000, Travis Casey wrote:
> On Monday, 16 February 98, Caliban wrote:
[snip]
> > In a related story, some wiseass once demonstrated that the only necessary
> > operators in the C programming language were incrementation,
> > decrementation, and equality. He wrote a huge series of functions that
> > demonstrated how you could simulate everything else with these two
> > operators. He had things like:
> 
> > int add(int num1,int num2) { while(1) { ++num1; --num2; if(num2==0) return
> > num1; } }
> 
> > The acrobatics got much, much worse. I'm not sure whether he was brilliant
> > or a complete moron. Probably a little of both. ;)
> 
> Umm... I think I know the kind of thing you're talking about, but
> you're off a bit.  The necessary operators are incrementation,
> decrementation, and what assembly language programmers would know as
> JNZ -- jump if not zero.  You can implement any mathematical algorithm
> with just these three operators -- the language they create can
> implement anything that a Turing machine can implement.  Thus, this
> language, Turing machines, and, if I remember right, two-stack push
> down automatons are the three possible "machines" are all equivalent
> machines, and are all used in computability theory, since they are
> each convenient for deriving different results.

There are quite a few equivalent "machines" characterized by being able
to calculate anything that is in theory calculable, while being amazingly
simple to describe and useless to program in. 

Others include:
State machine with two counters
State machine with one queue
Lambda calculus (Functions of one variable, no explicit recursion...)
Transformational grammars (when you see "abc" replace with "def")

The version of the above language that I learned about only had:
increment <varable>
decrement <variable> (but if variable was 0, don't change it)
while <variable> != 0, do {block of code}

All of these are far more useful for doing proofs than they are for
MUD design, and rather represent things to avoid when doing internal
languages.

Jon Leonard



More information about the mud-dev-archive mailing list