lpmoo-1.2/etc/
lpmoo-1.2/mudlib/
lpmoo-1.2/mudlib/etc/
lpmoo-1.2/mudlib/include/
lpmoo-1.2/mudlib/include/moo/
lpmoo-1.2/mudlib/lpc/
lpmoo-1.2/mudlib/std/auto/
lpmoo-1.2/mudlib/std/bfuns/
SOURCE LANGUAGE: MOO
====================

  Datatypes:  integer
              string
              list (array) - heterogeneous
              error value
              object reference - may refer to nonexistent object

  All values are immutable; lists are modified by creating new lists.

  The MOO grammar is relatively simple: the only available control structures
  are if, for, while, and "fork" (described below).

  The MOO database consists of numbered objects. Each object has some
  attributes (parent and children), a dynamic set of named properties, and a
  dynamic set of loosely named methods called "verbs". Each object has
  exactly one parent, and any number of children (single inheritance). An
  object inherits all properties and verbs from its ancestors; permission
  bits control which properties and which verbs the object may access.

  Verbs may call other verbs in the same object, or any other object,
  provided permission bits allow. Both the target object and the name of
  the verb may be computed at runtime. A limited number of "builtin"
  functions may also be called to perform special tasks. (The names of
  the builtin functions cannot be computed at runtime.)

  Verbs may override any of their ancestor's verbs, and can use a special
  pass() builtin function to call their inherited verb.

  The number of arguments to verbs and builtin functions is dynamically
  determined.

  Execution of a verb is initiated by the server. Each execution is called
  a "task" and is alotted a number of ticks to run. Ticks run down as
  execution progresses. If the ticks run out before the execution completes,
  the task is aborted.

  Execution can complete either by returning normally from the verb, or by
  a runtime error while running in "debug" mode. (Without debug mode, a
  runtime error simply generates and returns an error value.)

  A task may suspend itself, to continue running later. A task may also
  "fork" a new task, to be run later, while the current task continues
  running. Finally, a task can kill another queued (pending) task before that
  task begins to execute.

  Another variation of suspend() is read(), which suspends the task until
  a line of input is read from the network.

DESTINATION LANGUAGE: LPC
=========================

  Datatypes:  integer
              float
              string
              array - heterogeneous
              mapping (associative array) - heterogeneous
              object pointer - cannot refer to nonexistent object

  Arrays and mappings are mutable.

  The LPC grammar is practically identical to C. However, it does not
  have goto's, and pointers are hidden. (The standard C `*' pointer
  dereference operator is instead used to denote an array of some datatype.
  However, the keyword `mixed' can be used to specify a heterogeneous array.)

  The DGD database consists of named objects. Each object has a set of
  global variables and a collection of functions. Objects may inherit a
  subset of the variables and functions of one or more other objects
  (multiple inheritance). Class specifiers restrict which variables and
  functions may be inherited and/or overridden.

  Functions may call other functions in the same object (direct function
  call), or in any arbitrary object (indirect function call). Indirect
  function calls are made with a string reference to the function name along
  with a the (string) name of or (object) pointer to the object. A limited
  number of "builtin" functions can also be called to perform special tasks.

  The number of arguments to a function call is generally static, but can
  be made dynamic with special handling.

  Execution is initiated by the server. There is only one task, per se.
  The running task can request the delayed execution of another function in
  the same object (similar to the MOO fork). Delayed executions can also be
  aborted before they begin.

  Execution completes either by returning from the server-initiated function
  call, or by a runtime error. Errors will abort execution and resume at
  the most recently invoked catch() exception handler, if any. Execution
  may also run too long, consuming all of its alotted execution "cost," and
  will thus also cause a runtime error (recovery from this sort of error
  is more difficult than the others, however, since the exception handler
  won't be able to continue running, either).