Evaluates the given piece of MOO code and prints the resulting value. If the MOO code begins with one of the MOO language keywords ('if', 'for', 'while', 'fork', or 'return') or with the character ';', then the entire piece of code is treated as the program for a verb, with ';' appended to the end. Otherwise, 'return' is appended to the front and ';' is appended to the end and that string is treated as the code for a verb. In either case, the resulting verb is invoked and whatever value it returns is printed.
For programmers, this is such a mind-bogglingly useful thing to do that there is a simple abbreviation for this command; any command beginning with a semicolon (';') is treated as a use of 'eval'.
Eval treats specially a duplicated semicolon at the beginning. It enables you to make multi-statement programs within eval (but does not by default print the return value).
Eval-d (no ";" abbreviation for this) evaluates the following text exactly as eval, except that the "d" debug flag (see programmer's manual for explanation) is turned off. Thus errors will cause an error return value rather than a traceback.
If you set the programmer option `eval_time' to 1 (see "help @prog-options"), then eval will print out how many ticks and seconds the program required.
Examples:
eval 3 + 4
=> 7
;3+4
=> 7
;for x in (player.aliases) player:tell(x); endfor
Haakon
Wizard
ArchWizard
=> 0
;;l = {}; for i in [1..10] l = {@l, i}; endfor return l
=> {1, 2, 3, 4, 5, 6, 7, 8, 9, 10}
eval-d 8 + "foo"
=> E_TYPE (Type mismatch)
You may customize your evaluation environment. The player property .eval_env may contain statements to be executed prior to any evaluated program. Two caveats: This will throw off the tick count. You can account for additional ticks inserted by your environment with the .eval_ticks property; just set it to the number of ticks you'd like subtracted from the total. Additionally, if you make a syntax error in your program, the line reported will be wrong (it will count those initial statements), and if you make an error in the eval_env itself, you can be in deep trouble. Despite these drawbacks, the eval_env property can be quite useful. The following is a sample:
You can also define textual substitutions in a separate property, called eval_subs. These are discouraged, however, for anything that can be done with variable assignments, because the overhead of replacing the strings in the evaluated program is significant. However, some things, such as substituting characters which can't be typed easily on one keyboard (e.g. "[]" is difficult to type on some IBM keyboards), can only be done by textual substitutions. Note that the eval substitutions are also interpreted by the verb editor when "eval_subs" is selected in your .edit_options property (see "help editors"). This adds to their overhead, but again, makes it possible for people to program who otherwise can't type the full character set. Remember: Don't use eval_subs unless you really have to!