{FnDef {FnName COND} {FnArgs CLAUSE{SUB 1} CLAUSE{SUB 2} {ellipsis} CLAUSE{SUB K}}
{Type NOSPREAD NLAMBDA}
{Text
The conditional function of Interlisp, {fn COND}, takes an indefinite number of arguments, called {index COND clause}clauses.  Each {arg CLAUSE{sub i}} is a list of the form {lisp ({arg P{sub i}} {arg C{sub i1}} {ellipsis} {arg C{sub iN}})}, where {arg P{sub i}} is the predicate, and {arg C{sub i1}} {ellipsis} {arg C{sub iN}} are the consequents.  The operation of {fn COND} can be paraphrased as:

IF
{arg P{sub 1}}
THEN
{arg C{sub 11}} {ellipsis} {arg C{sub 1N}}
ELSEIF
{arg P{sub 2}}
THEN
{arg C{sub 21}} {ellipsis} {arg C{sub 2N}}
ELSEIF
{arg P{sub 3}} {ellipsis}


The clauses are considered in sequence as follows: the predicate {arg P{sub 1}} of the clause {arg CLAUSE{sub i}} is evaluated.  If the value of {arg P{sub 1}} is "true" (non-{lisp NIL}), the consequents {arg {arg C{sub i1}} {ellipsis} {arg C{sub iN}}} are evaluated in order, and the value of the {fn COND} is the value of {arg C{sub iN}}, the last expression in the clause.  If {arg P{sub 1}} is "false" ({fn EQ} to {lisp NIL}), then the remainder of {arg CLAUSE{sub i}} is ignored, and the next clause, {arg CLAUSE{sub i+1}}, is considered.  If no {arg P{sub i}} is true for {it any} clause, the value of the {fn COND} is {lisp NIL}.

Note:  If a clause has no consequents, and has the form {lisp ({arg P{sub i}})}, then if {arg P{sub i}} evaluates to non-{lisp NIL}, it is returned as the value of the {lisp COND}.  It is only evaluated once.

Example:

{lispcode
_ (DEFINEQ (DOUBLE (X)
               (COND ((NUMBERP X) (PLUS X X))
                     ((STRINGP X) (CONCAT X X))
                     ((ATOM X) (PACK* X X))
                     (T (PRINT "unknown") X)
                     ((HORRIBLE-ERROR))]
(DOUBLE)
_ (DOUBLE 5)
10
_ (DOUBLE "FOO")
"FOOFOO"
_ (DOUBLE 'BAR)
BARBAR
_ (DOUBLE '(A B C))
"unknown"
(A B C)}

A few points about this example:  Notice that {lisp 5} is both a number and an atom, but it is "caught" by the {fn NUMBERP} clause before the {fn ATOM} clause.  Also notice the predicate {lisp T}, which is always true.  This is the normal way to indicate a {fn COND} clause which will always be executed (if none of the preceeding clauses are true).  {lisp (HORRIBLE-ERROR)} will never be executed.


Note:  The {lisp IF} statement ({PageRef Tag IFstatement}) provides an easier and more readable way of coding conditional expressions than {fn COND}.
}}



{FnDef {FnName AND} {FnArgs X{SUB 1} X{SUB 2} {ellipsis} X{SUB N}}
{Type NOSPREAD NLAMBDA}
{Text
Takes an indefinite number of arguments (including zero), that are evaluated in order.  If any argument evaluates to {lisp NIL}, {fn AND} immediately returns {lisp NIL} (without evaluating the remaining arguments).  If all of the arguments evaluate to non-{lisp NIL}, the value of the last argument is returned.  {lisp (AND)  =>  T}.
}}


{FnDef {FnName OR} {FnArgs X{SUB 1} X{SUB 2} {ellipsis} X{SUB N}}
{Type NOSPREAD NLAMBDA}
{Text
Takes an indefinite number of arguments (including zero), that are evaluated in order.  If any argument is non-{lisp NIL}, the value of that argument is returned by {fn OR} (without evaluating the remaining arguments).  If all of the arguments evaluate to {lisp NIL}, {lisp NIL} is returned.  {lisp (OR)  =>  NIL}.
}}


{fn AND} and {fn OR} can be used as simple logical connectives, but note that they may not evaluate all of their arguments.  This makes a difference if the evaluation of some of the arguments causes side-effects.  Another result of this implementation of {fn AND} and {fn OR} is that they can be used as simple conditional statements.  For example: {lisp (AND (LISTP {arg X}) (CDR {arg X}))} returns the value of {lisp (CDR {arg X})} if {arg X} is a list cell, otherwise it returns {lisp NIL} without evaluating {lisp (CDR {arg X})}.  In general, this use of {fn AND} and {fn OR} should be avoided in favor of more explicit conditional statements in order to make programs more readable.



{Begin Note}
SELECT de-documented.  It doesn't seem to be used in system files (EXCEPT as a PROG tag).  Def moved to Stuff.SELECT.

Ron says:  SELECTxx fns should be conceptually like (SEL FN X . CLAUSES), where FN is wrapped around each select key (one atom or one list) so
(SELECTQ ...)  <==>  (SEL 'QUOTE ...)
(SELECTC ...)   <==>  (SEL 'CONSTANT ...)
(SELCHARQ ...)   <==>  (SEL 'CHARCODE ...)
so far so good...but unfortunately SELECT has somewhat different semantics, so it doesn't fit into this model.  In particular, (SELECT X ... ( (A B C) ...) ...) evaluates A, B, and C individually, rather than doing something to (A B C).

Also, compiled SELECT doesn't do the right thing if infix operators are in selection keys or rest of clauses.
{End Note}

{FnDef {FnName SELECTQ}
{FnArgs X CLAUSE{SUB 1} CLAUSE{SUB 2} {ellipsis} CLAUSE{SUB K} DEFAULT}
{Type NOSPREAD NLAMBDA}
{Text

Selects a form or sequence of forms based on the value of its first argument {arg X}.  Each clause {arg CLAUSE{sub i}} is a list of the form
{lisp ({arg S{sub i}} {arg C{sub i1}} {ellipsis} {arg C{sub iN}})}
where {arg S{sub i}} is the selection key.
The operation of {fn SELECTQ} can be paraphrased as:

IF
{arg X} = {arg S{sub 1}}
THEN
{arg C{sub 11}} {ellipsis} {arg C{sub 1N}}
ELSEIF
{arg X} = {arg S{sub 2}}
THEN
{ellipsis}
ELSE
{arg DEFAULT}.

If {arg S{sub i}} is an atom, the value of {arg X} is tested to see if it is {fn EQ} to {arg S{sub i}} (which is not evaluated).  If so, the expressions {arg C{sub i1}} {ellipsis} {arg C{sub iN}} are evaluated in sequence, and the value of the {fn SELECTQ} is the value of the last expression evaluated, i.e., {arg C{sub iN}}.

If {arg S{sub i}} is a list, the value of {arg X} is compared with each element
(not evaluated) of {arg S{sub i}}, and if {arg X} is {fn EQ} to any one of them, then {arg C{sub i1}} {ellipsis} {arg C{sub iN}} are evaluated as above.

If {arg CLAUSE{sub i}} is not selected in one of the two ways described,
{arg CLAUSE{sub i+1}} is tested, etc., until all the clauses have been tested.
If none is selected, {arg DEFAULT} is evaluated, and its value is returned as the value of the {fn SELECTQ}.  {arg DEFAULT} must be present.

An example of the form of a {fn SELECTQ} is:

{lispcode
[SELECTQ MONTH
   (FEBRUARY (if (LEAPYEARP) then 29 else 28))
   ((APRIL JUNE SEPTEMBER NOVEMBER) 30)
   31]}

If the value of {lisp MONTH} is the litatom {lisp FEBRUARY}, the {fn SELECTQ} returns 28 or 29 (depending on {lisp (LEAPYEARP)});  otherwise if {lisp MONTH} is {lisp APRIL}, {lisp JUNE}, {lisp SEPTEMBER}, or {lisp NOVEMBER}, the {fn SELECTQ} returns 30;  otherwise it returns 31.


{fn SELECTQ} compiles open, and is therefore very fast; however, it will not work if the value of {arg X} is a list, a large integer, or floating point number, since {fn SELECTQ} uses {fn EQ} for all comparisons.
}}


Note:  The function {fn SELCHARQ} ({PageRef Fn SELCHARQ}) is a version of {fn SELECTQ} that recognizes {fn CHARCODE} litatoms.




{FnDef {FnName SELECTC}
{FnArgs X CLAUSE{SUB 1} CLAUSE{SUB 2} {ellipsis} CLAUSE{SUB K} DEFAULT}
{Type NOSPREAD NLAMBDA}
{Text
"{fn SELECTQ}-on-Constant."  Similar to {fn SELECTQ} except that the selection keys are evaluated, and the result used as a {fn SELECTQ}-style selection key.

{fn SELECTC} is compiled as a {fn SELECTQ}, with the selection keys evaluated at compile-time.  Therefore, the selection keys act like compile-time constants (see {PageRef Fn CONSTANT}).  For example:

{lispcode
[SELECTC NUM
   ( (for X from 1 to 9 collect (TIMES X X)) "SQUARE" )
   "HIP"]}

compiles as:

{lispcode
[SELECTQ NUM
   ( (1 4 9 16 25 36 49 64 81) "SQUARE" )
   "HIP"]}
}}



{FnDef {FnName PROG1} {FnArgs X{SUB 1} X{SUB 2} {ellipsis} X{SUB N}}
{Type NOSPREAD NLAMBDA}
{Text
Evaluates its arguments in order, and returns the value of its first argument {arg X{sub 1}}.  For example, {lisp (PROG1 X (SETQ X Y))} sets {lisp X} to {lisp Y}, and returns {lisp X}'s original value.
}}


{FnDef {FnName PROG2} {FnArgs X{SUB 1} X{SUB 2} {ellipsis} X{SUB N}}
{Text
Similar to {fn PROG1}.  Evaluates its arguments in order, and returns the value of its second argument {arg X{sub 2}}.

{note arg! takes advantage of fact that evaluator evals ALL args given to a spread fn ... even excess ones.}
}}



{FnDef {FnName PROGN} {FnArgs X{SUB 1} X{SUB 2} {ellipsis} X{SUB N}}
{Type NOSPREAD NLAMBDA}
{Text
{fn PROGN} evaluates each of its arguments in order, and returns the value of its last argument.  {fn PROGN} is used to specify more than one computation where the syntax allows only one, e.g., {lisp (SELECTQ {ellipsis} (PROGN {ellipsis}))} allows evaluation of several expressions as the default condition for a {lisp SELECTQ}.
}}



{FnDef {FnName PROG}
{FnArgs VARLST E{SUB 1} E{SUB 2} {ellipsis} E{SUB N}}
{Type NOSPREAD NLAMBDA}
{Text
This function allows the user to write an ALGOL-like program containing Interlisp expressions (forms) to be executed.  The first argument, {arg VARLST}, is a list of local variables{index local variables} (must be {lisp NIL} if no variables are used).  Each atom in {arg VARLST} is treated as the name of a local variable and bound to {lisp NIL}.  {arg VARLST} can also contain lists  of the form {lisp (atom form)}.  In this case, {lisp atom} is the name of the variable and  is bound to the value of {lisp form}.  The evaluation takes place before any of the bindings are performed, e.g., {lisp (PROG ((X Y) (Y X)) {ellipsis})} will bind local variable {lisp X} to the value of {lisp Y} (evaluated {it outside} the {fn PROG}) and local variable {lisp Y} to the value of {lisp X} (outside the {fn PROG}).
An attempt to use anything other than a literal atom as a {fn PROG} variable will cause an error, {index ARG NOT LITATOM Error}{lisp ARG NOT LITATOM}.  An attempt to use {lisp NIL} or {lisp T} as a {fn PROG} variable will cause an error, {index ATTEMPT TO BIND NIL OR T Error}{lisp ATTEMPT TO BIND NIL OR T}.

The rest of the {fn PROG} is a sequence of non-atomic statements (forms) and litatoms (labels).  The forms are evaluated sequentially;{index PROG label} the labels serve only as markers.  The two special functions {fn GO} and {fn RETURN} alter this flow of control as described below.  The value of the {fn PROG} is usually specified by the function {fn RETURN}.  If no {fn RETURN} is executed before the {fn PROG} "falls off the end," the value of the {fn PROG} is {lisp NIL}.

{Note Example!!}
}}


{FnDef {FnName GO} {FnArgs X}
{Type NOSPREAD NLAMBDA}
{Text
{fn GO} is used to cause a transfer in a {fn PROG}.  {lisp (GO L)} will cause the {fn PROG} to evaluate forms starting at the label {lisp L} ({fn GO} does not evaluate its argument).  A {fn GO} can be used at any level in a {fn PROG}.  If the label is not found, {fn GO} will search higher progs {it within the same function,} e.g., {lisp (PROG {ellipsis} A {ellipsis} (PROG {ellipsis} (GO A)))}.
If the label is not found in the function in which the {fn PROG} appears, an error is generated, {lisp UNDEFINED OR ILLEGAL GO}.{index UNDEFINED OR ILLEGAL GO Error}
}}


{FnDef {FnName RETURN} {FnArgs X}
{Text
A {fn RETURN} is the normal exit for a {fn PROG}.
Its argument is evaluated and is immediately returned the value
of the {fn PROG} in which it appears.
}}


Note:  If a {fn GO} or {fn RETURN} is executed in an interpreted function which is not a {fn PROG}, the {fn GO} or {fn RETURN} will be executed in the last interpreted {fn PROG} entered if any, otherwise cause an error.{index ILLEGAL RETURN Error}{index UNDEFINED OR ILLEGAL GO Error}

{fn GO} or {fn RETURN} inside of a compiled function that is not a {fn PROG} is not allowed, and will cause an error at compile time.

As a corollary, {fn GO} or {fn RETURN} in a functional argument, e.g., to {fn SORT}, will not work compiled.  Also, since {fn NLSETQ}'s and {fn ERSETQ}'s compile as {it separate} functions, a {fn GO} or {fn RETURN} {it cannot} be used inside of a compiled {index NLSETQ FN}{fn NLSETQ} or {index ERSETQ FN}{fn ERSETQ} if the corresponding {fn PROG} is outside, i.e., above, the {fn NLSETQ} or {fn ERSETQ}.


{Note Is the above also true for ERRORSET in general (on which NLSETQ and ERSETQ are based)? ---mjs  <-- No! ERRORSET doesn't create a seperate function ... however, it seems that GO and RETURN won't work under a compiled call to ERRORSET anyway (compiles OK, but gives undef or illegal GO error on execution).

Heres the story: it seems that GO (and RETURN too) will not work if inside a function called (via fn call) from a compiled function containing a PROG.  If the "function" is actually a macro, so that it is compiled open, or is one of the specially-compiled fns (PROG, COND, etc.), then it works.  The important thing is the function call from a compiled function containing a PROG.  This is not immediately observable by the random user.  Should this explaination be documented??  (perhaps in compiler section??)}