GDL is intended to be an easily used, yet powerful, tool for people who have little programming experience, but who wish to design Xconq game modules. For those who have programmed in Lisp before, GDL uses a similar syntax, but knowledge of Lisp is not required to develop Xconq games. Elements of GDL include such things as numbers, lists, and tables.
Formally, GDL is a declarative, or nonprocedural, language, rather
than an imperative language. This means that most of the time, you can
declare lists, tables, and forms (which will be discussed later) in
any order you like. There are two significant, though not unreasonable,
restrictions however. The first is that any symbol, such as a variable
or the name of a type, must be defined before it is used. The second is
that a symbol must be used in an appropriate context or scope. This is
basically to say that you can only assign properties to things for
which those properties would make sense. Keep in mind that definitions
can be overwritten with the use of set and add (which will
also be discussed later), and the order in which they are used is
important.
The Xconq interpreter parses GDL declarations into various lexical elements, or tokens. These include numbers, strings, symbols, comment delimiters, and list/form/table delimiters.
Numbers are introduced by a decimal digit, plus, or minus signs. They
may contain only decimal digits, a decimal point, and be followed
(immediately, no whitespace allowed) by a percent sign. Numbers are
used where integer quantities, percentages (which may meaningfully
exceed 100% in many cases), or parts per 10,000 (0.01% increments) are
expected. Typically numbers are positive. Unless otherwise stated,
the default value for properties that take numeric values is 0.
Also of interest is the fact that -1 is often used to indicate
special behavior of a property or table element, such as "turning off"
the property, or inheriting a value set in another table. Examples of
numeric values include the following: 99, 65.2%,
4.00, and -1.
Strings are sequences of characters (letters, digits, punctuation marks,
etc...) enclosed by doublequotes (").
They may contain any character except ASCII NUL ('\0'). To
include a doublequote, use backslash, as in "a \"quoted\"
string". To include a nonprinting or eight-bit character (often
associated with international characters or ANSI graphics), use
backslash followed by three octal digits, which will be interpreted as
an eight-bit character code. (This is mostly the same syntax as in C.)
Note that game design files may be passed over networks and between
different kinds of computer systems, so non-ASCII characters should not
be inserted verbatim into strings. In places where string values are
expected, the default is "", unless otherwise stated.
Symbols are sequences of characters that don't include any of the other
special characters. If you wish to include such characters in a symbol,
enclose it in vertical bars, for example |foo bar|. (The bars
are not part of the symbol.) Symbols are case-sensitive, but this will
be changed eventually. Examples of symbols include: acp-per-turn,
|coastal waters|, and size.
Numbers, strings, and symbols all belong to a kind called an atom. There are other elements of GDL which are not atoms; these are comments and lists.
Comments are enclosed either within #| |#, or else extend from a
semicolon ; to the end of the line. A comment is equivalent to
whitespace, so a#|bcd|#e is the same as a e, not
ae. The #| |# style comments can be nested (placed inside
one another) without trouble, and are allowed to extend across multiple
lines. Note that # by itself is nothing special and can be used as
a normal character in, say, a symbol.
Lists are a sequence of atoms and/or other lists enclosed in parentheses.
Empty lists can either be represented by the symbol nil or by the
list (). There is nothing similar to the "dotted pairs" of Lisp;
if you don't know what dotted pairs are, then don't worry about it.
Tables and forms, both of which will be discussed in more detail later,
are delimited by parentheses in the same manner as lists. Indeed, forms
can be thought of as lists that start with a special symbol, or keyword.
Lists might look like (100 90 0), ("Lansing" "Denver"),
((10 0 10) (5 10 15)), (cv bb dd), ("1 atom"), or
nil. Some examples of things which are not lists are
"1 atom", which, like it says, is one atom, and:
(10 20 ; This comment can cause problems. )
because everything past the semicolon is ignored. An acceptable
alternative would be:
(10 20 #| This comment will not cause problems. |#)
All of the things mentioned above may range up to a very large size. In
particular, numbers can generally hold values up to 32767 (sometimes
referred to as TABHI or PROPHI in the documentation), though most
games use values such as 99, 999, or 9999 for a value
which is too large to ever be reached.
Most tables are limited to be 127x127 at largest (which is really quite
large); this is due to Xconq's present internal constraints on the
number of unit types, terrain types, et cetera, that may be defined.
Although strings and symbols are allowed to be quite large, one should
exercise caution and keep them around a 100 characters or less in length,
lest bugs (or "unexpected features") be tempted to emerge.
True/false values are just numbers, with no special characteristics.
GlobalConstant: true
These constants are symbolic forms for 1 and 0. They are
identical to numbers, but more descriptive for parameters that are
boolean-valued.
Unit, material, and terrain types are distinct objects. However, they can be considered to have numeric "indices" assigned in order of the types' definition. These numbers are not directly visible in GDL, but they often affect sorting and ordering.
You may also supply numbers as dice specs in some cases.
The syntax of the dice specs should be familiar to those who play
various RPGs.
There are two types of dice in Xconq: Type 1 dice and
Type 2 dice.
Type 1 dice specs allow values to span both the positive and negative
integers, including zero.
The syntax of Type 1 dice specs takes the form of
ndss[+ooo], or
ndss[-ooo], where n is the number of
dice, ss is the number of sides per die, and ooo is an
offset to be added to or subtracted from the dice roll.
Type 2 dice specs restrict value ranges to be either wholly negative or
wholly positive. The value 0 is not allowed in the range.
The syntax of Type 2 dice specs takes the form of
-ndss[-ooo], or
ndss[+ooo].
For both types of dice, ss is restricted from 2 to 17,
inclusive.
For Type 1 dice, n is restricted from between 1 and 8,
inclusive, and ooo is restricted from between -128 and
127, inclusive.
For Type 2 dice, n can be from between 1 and 8, inclusive,
with an offset restricted from 0 and 127, inclusive, or
n can be from between -8 and -1, inclusive, with an
offset restricted from -127 and 0, inclusive.
Both types of dice are 1-based, so they behave as you would expect.
For example, 1d8 yields values between 1 and 8,
inclusive, and 3d6 yields values between 3 and 18,
inclusive. The dice spec 4d10+5 yields values between 9
and 45, inclusive.
Note: The range of dice is quite limited because of the way Xconq stores
them internally. This problem may remedied at some later time.
Note: One cannot write chained dice specs, such as 3d5,1d4+2.
All dice specs have only one homogeneous type of die involved.
Note: For those who have designed games in the past, yes, the present
dice implementation does differ from the older implementation, which
was 0-based, and allowed for n and ss to be 0. This old
behavior is no longer supported.
Note: Many things that accept dice specs can also take a restricted range
of plain integers as well. For example, a dice table may be able to also
take on plain integer values from -16384 to 16383.
Descriptions of values in this manual follow the conventions listed here.
For parameters described as t/f, both 1, 0 and
true, false may be used. Parameters described as n
and n% are numbers. Parameters described as dist or
length are also numbers, but are in the unit of measure for
lengths. Parameters described as str or string are strings.
Parameters described as u or ui, m or mi, and t or ti, are values that must be unit, material, or terrain types, respectively.
Parameters described as utype-value-list match unit types with values. They can have several forms:
(n1 n2 ...) matches n1 with type 0, etc in order.
((u1 n1) (u2 n2) ...) evaluates u1 to get a unit type,
then matches it with n1. u1 etc may also be a list of
types, in which case all the types get matched with n1.
Other types of lists, such as those defined as side-value-list, are interpreted similarly. For all of these, multiple assignments to the same type etc will overwrite quietly.
List values described as interpolation-list are lists of pairs
used to derive numerical values by interpolating between the listed
values. The form of an interpolation list is always ((key1 val1)
(key2 val2) ...)), where keyi and vali are numbers. If the
input value inp to an interpolation matches keyi, the result
value is vali. If it is between keyi and keyi+1, then
the result is gotten by linear interpolation, with the result value
falling somewhere between vali and vali+1. Fractional
values always round down. The keyi must occur in non-decreasing
order; it is legitimate for two consecutive keys to be identical, in
which the result value will be the value associated with the first key.
If the input value is outside the domain specified by the keys, the
result depends on the particular parameter; some will extrapolate in
some appropriate fashion, while others will generate an error or
warning. To be safe, one should set up key-value pairs for the min and
max of the input domain.
One place where an interpolation list is used is the
acp-damage-effect property that may be assigned to unit types.
Suppose we have a unit type named battleship, which has 30 hit
points and 6 action points when fully healthy. When the battleship
reaches various levels of damage, we want to affect its ability to
act to simulate such things as a gun turret or propeller being destroyed.
To do this, we can assign the acp-damage-effect property in
perhaps the following way:
(unit-type battleship (acp-damage-effect ((0 0) (10 2) (20 4) (30 6))) )
Now how many action points will the battleship have when it has 15 hit points? The answer should be 3 action points. When it has 14 hit points? 2 action points (remember that fractional parts round down). When it has 16 hit points? Again, 3 action points. When it has 10 hit points? 2 action points (this can be read directly from the interpolation list). When it has 4 hit points? 0 action points.
Some values may be boolean expressions. Boolean expressions are lists
headed by the keywords and, or, and not, and may
nest recursively. For instance, the expression
(and (or false (not false)) true)
is always true. In some contexts, values other than true and
false may appear, in which case the interpretation of those
values depends on the context.
Some numeric values are stochastic, meaning that they are partly fixed and partly probabilistic in effect. The most common form of this is values where the part > 100 is divided by 100, while the value mod 100 is the probability to add 1 to the first part. Thus a value of 425 works out to a value of 4, 3/4 of the time, and to 5, 1/4 of the time, on average.
Unless otherwise stated, all numeric values default to 0, all
string values default to "", and all form values default to
(). If one of these defaults has a notable consequence, such as
inability to perform some action, that will be mentioned.
A form is any single expression that appears in the file.
A GDL file consists of a sequence of forms. Most forms of interest will
be lists whose first element is a symbol identifying the form. For
instance, a form beginning with the symbol side declares a side
object. When the file containing such a form is read, Xconq will
create a side object and fill in any properties as specified by the
form. (Properties are like properties or attributes - most GDL objects
have some.)
In most contexts, Xconq will evaluate an expression before
using it, such as when filling in an object's property. Numbers and
strings evaluate to themselves, while symbols evaluate to their
bindings, as set by set or define. Lists evaluate to a
list of the same length, but with all the elements evaluated, unless the
first element of the list is a function. In that case, the remaining
elements of the list are evaluated and given to the function, and its
result will be the result.
A table is a two-dimensional array of values indexed by types. Indices can be any pair of unit, material, or terrain type. The set of tables is fixed by Xconq, and all are described below.
Form: table table-name items...
This is the general form to fill in a table. The table named by
table-name is filled in from the items. If an item is an
atom, then every position in the table is filled in with that item,
overwriting any previously-specified values. If an item is a list, it
must be a three-element list of the form (type1 type2
value). If both type1 and type2 are single types,
then value will be put into the table at the position indexed by
the two types. If one of type1 or type2 evaluates to a
list, Xconq will iterate over all members of the list while keeping
the other type constant, while if both type1 and type2 are
lists, then Xconq will iterate over all pairs from the two lists.
The values used during iteration depend on whether the value is a
list. If value is an atom, then that value will just be used on
every iteration. If a list, then Xconq will use successive elements
of the list while iterating.
If the first member of items is the symbol add, then the
rest of the items will add to the existing contents of the table rather
than clearing to its default value first.
The following forms are all equivalent:
(table foo (a y 1) (b y 2) (c y 3) (a z 9) (b z 9) (c z 9)) (table foo ((a b c) y (1 2 3)) ((a b c) (z) 9)) (define v1 (a b c)) (table foo (v1 y (1 2 3)) (v1 z 9)) (table foo ((a b c) (y z) ((1 2 3) (9 9 9)))) (table foo (a y 1) (b y 2) (c y 3)) (table foo add ((a b c) z 9))
Since forms normally define or create new objects, GDL defines the
add form to modify existing objects.
Form: add objects property new-values...
This form evaluates the atom or list objects to arrive at the set of objects to be modified. Then it uses the new-values to write new data into the property named property of those objects. The new-values may be a single number or string, or a list.
Most of the symbols used in a game module are the predefined ones described in this manual. Others are attached to types when the types are defined, and still others name objects like units and sides. You can also define and set your own symbols to arbitrary values.
Form: define symbol value
This form defines the symbol symbol to be bound to the result of evaluating value. If symbol is already defined, Xconq will issue a warning, and ignore this form.
Form: set symbol value
This form rebinds the already-bound symbol symbol to be bound to the result of evaluating value. If symbol is not bound already, then Xconq will issue a warning, but proceed anyway.
Form: undefine symbol
This form destroys any binding of the symbol. This is allowed for any symbol, including already-unbound symbols.
Some transformations can be performed on lists. All of these are transforms are non-destructive, which is to say that the original list is not altered, but a new list with the transformation applied is returned as a result.
Function: quote form...
This function prevents any evaluation of form. (This implies that the abovementioned evaluation of the argument list does not happen for this "function".)
Function: list form...
This function makes a list out of all the form.
Function: append form...
NOTE: If you are not a Lisp programmer, be cautious about inferring what this
function does based on its name.
This function "appends" all the form (which may be lists or not)
into a single list. Another way to state the above is: append
gathers everything following it into one list, "flattening out" any lists
it encounters, and returns the result.
Function: remove item list
This function removes item from every place that it occurs in list, returning the resulting list. If item is not found in list, then list is returned.
Function: remove-list list1 list2
This function removes each item of list list1 from every place that it occurs in list2, returning the resulting list. If no item in list1 is found in list2, then list2 is returned.
Some examples of the above commands:
The following three are all equivalent examples of quoting; they leave the
list contents unevaluated when the list is first read.
(quote not "independent")
'(not "independent")
`(not "independent")
Quoting is useful for things that should not be evaluated immediately, but
may be used Xconq later during run time (after the game has been read in).
These things include synthesis-methods and possible-sides.
Here is an example of appending:
(define light-sea-u* (destroyer frigate))
(define heavy-sea-u* (battleship carrier))
(define sea-u* (append light-sea-u* heavy-sea-u*))
In the above, two lists are defined. Then those two lists are joined
into a single list, sea-u*. Note that sea-u* would
be equivalent to the following definition:
(define sea-u* (destroyer frigate battleship carrier))
and not:
(define sea-u* ((destroyer frigate) (battleship carrier)))
because the lists were flattened.
Here is another example of appending:
(define wyrms (red-wyrms blue-wyrms green-wyrms))
(define dragons (append wyrms dragon-turtle))
In this case wyrms is a list, while dragon-turtle might be
an atom. The definition of dragons would therefore be equivalent to:
(define dragons (red-wyrms blue-wyrms green-wyrms dragon-turtle))
Here is an example of removing a single item:
(define land-combat-u* (infantry mechinf cavalry armor))
(define motor-land-combat-u* (remove infantry land-combat-u*))
The definition of motor-land-combat-u* would then be equivalent to:
(define motor-land-combat-u* (mechinf cavalry armor))
Here is an example of removing multiple items:
(define monsters (daleks sontarans cybermen ice-warriors))
(define bad-robots (remove-list (sontarans ice-warriors) monsters))
And here is a more sophisticated example of removing and appending:
(define nco-ranks (chief senior-chief master-chief))
(define low-ranks (ensign lieutenant-jg lieutenant commander))
(define high-ranks (captain commodore r-admiral v-admiral admiral))
(define rank-sets (nco-ranks low-ranks high-ranks))
(define com-ranks (append (remove nco-ranks rank-sets)))
which is equivalent to:
(define com-ranks (append low-ranks high-ranks))
which is equivalent to:
(define com-ranks (ensign lieutenant-jg lieutenant commander captain commodore r-admiral v-admiral admiral))
One should note that in the above example, a list, nco-ranks, was
treated as the item to remove.
The above example can also be done in terms of remove-list instead:
(define all-ranks (append nco-ranks low-ranks high-ranks))
(define com-ranks (remove-list nco-ranks all-ranks))
GDL supports some basic mathematical operations. Addition, subtraction, multiplication, and division are all available. To use an operator, it must be at the start of a new form; everything after it until the end of that form will be interpreted as operands.
All four of the basic operators can operate on numbers, lists of numbers, and symbols which are bound to either numbers or lists of numbers, and any combination thereof. The only constraint is that all lists must be the same lengths as one another, with the exception that empty lists are allowed and will simply be skipped over. When a number is operated with a list, that number is operated with each item of the list. When a list is operated with a list, each item of the first operand list is operated with the item in the corresponding position of the second operand list. Thus, when a number is operated with a number, a number is always returned as the result. When a number is operated with a list or vice versa, a list is always returned as the result. When a list is operated with a list, then another list is always returned as the result.
Operators forms can be nested inside one another. Multiple operators within the same operator form are not allowed. Precedence is determined by evaluating the innermost (most deeply nested) operators first. Association is from left to right.
The results of operations are still subject to the same constraints as
numbers and lists produced without operations. Value limits, such as
32767 and -32768, still apply. Because of this, you should
be careful not to multiply, add, or subtract quantities that are too large
in numeric magnitude or you may end up with undesired results.
Another thing to note about numbers is that, to Xconq, 10,
10%, and 0.10 are all the same thing. Likewise for
400, 400%, and 4.00. Generally, when designing a
game, you should not have to worry about how these number representations
are handled internally; that is for the Xconq code writers to worry about.
However, if you are doing math on numbers, this knowledge does come into
play, unfortunately. For instance, if you use GDL to multiply a plain
integer by a percent, you will not get a result that is a percentage of the
integer. Some of the examples below will show you the correct way to deal
with this and other similar situations. Also note that dice specs are
treated as numbers internally in Xconq, and so there is a special way to
manipulate them as well. Again, this will be demonstrated in the examples
below.
Function: + operands...
Sums all of the operands together. If only one operand is present,
then that operand is returned unaltered. If no operands are present, then
the additive identity, 0, is returned.
Function: - operand1 operands...
Subtracts all of the operands from operand1. If only
operand1 is present, then 0 minus operand1 is
returned. If no operands are present, then it returns nil.
Function: * operands...
Multiplies all the operands together. Must have at least two operands
to multiply, or else it returns nil, except when no operands
are specified, in which case it returns the multiplicative identity,
1.
Function: / operand1 operands...
Divides all of the operands into operand1. If less than
two operands are present, then it returns nil.
NOTE: Unlike Common Lisp, GDL does not support rational numbers, and
therefore it is not possible for division with a single operand to return
the reciprocal of that operand as Common Lisp implementations do.
Furthermore, since all arithmetic is integer arithmetic in GDL, values
between integers cannot be represented; numbers between 0 and
1 will appear as 0.
Here are some examples of addition:
(+ 1 1)
returns 2
(+ 1 2 3 4 5)
returns 15
(+ 1 (-1 2))
returns (0 3)
(+ (50% 75%) 25%)
returns (75% 100%)
(+ (0.33 0.67) (0.67 1.33))
returns (1.00 2.00)
(define FOOD_RATS_LOSS 20%)
(define FOOD_ROT_LOSS 10%)
(define FOOD_LOSS (+ FOOD_RATS_LOSS FOOD_ROT_LOSS))
is the same as
(define FOOD_LOSS 30%)
(+ (10 20) (30 40) (50 60) (70 80) (90 0))
returns (250 200)
(+ 10 25 (+ 20 25))
returns 80
(+ -4)
returns -4
(+ 190)
returns 190
(+)
returns 0
Here are some examples of subtraction:
(- 10 5)
returns 5
(- 15 5 4 3 2)
returns 1
(- 10 (4 5))
returns (6 5)
(- (10 15) 10)
returns (0 5)
(- (1.00 1.50) (0.25 0.45))
returns (0.75 1.05)
(- 50%)
returns -50%
(define burden 25%)
(define speed-effect (- burden))
is equivalent to
(define speed-effect -25%)
Here are some examples of multiplication:
(* 5 5)
returns 25
(* 5 4 3 2 1)
returns 120
(* -1 (5 10))
returns (-5 -10)
(* (25% 50%) 5)
returns (125% 250%)
(* (2.00 5.00) (10 5))
returns (20.00 25.00)
(*)
returns 1
Here are some examples of division:
(/ 14 2)
returns 7
(/ 15 2)
also returns 7
(/ 80 100)
returns 0
(/ 12 (6 4 3 2))
returns (2 3 4 6)
(/ (15 10) 5)
returns (3 2)
(/ (100% 250%) (2 5))
returns (50% 50%)
To take a percentage of a number, you need to do something like the
following:
(/ (* 4 50%) 100)
which returns 2
To properly multiply a number by a decimal factor, you must do something
like the following:
(/ (* 5 4.00) 100)
which returns 20
(/ (* 40 0.25) 100)
which returns 10
(/ (* 3.00 3.00) 100)
which returns 9.00, or 900 if you prefer to see it that way
To properly multiply a number by a fraction, try something like the
following:
(/ (* full-speed 4) 5)
which returns four-fifths of full-speed
For those seeking to do domething perhaps a bit trickier with GDL arithmetic
operators, there is the manipulation of dice specs.
To properly manipulate dice specs requires some understanding of how
Xconq internally represents dice. Dice are stored in a 2-byte word.
For values between -16384 and 16383, inclusive, this is treated
as a short integer, and can be manipulated in a straightforward way.
Values above 16383 and below -16384 are used by Xconq to
encode dice specs into the internal representation of dice, where relevant.
All positive dice specs (Type 1 with positive offset and wholly-positive
Type 2) are encoded starting at 16384 up to and including
32767.
Likewise, all negative dice specs (Type 1 with negative offset and
wholly-negative Type 2) are encoded starting at -16385 down to and
including -32768.
Thus, to get a positive dice spec, one must always start with 16384,
and to get a negative dice spec, one must always start with -16385.
A value of 16384 by itself is equivalent to 1d2.
The least-significant 7 bits (bits 0 through 6, inclusive) are used to
encode the offset. Thus, 16385 is equivalent to 1d2+1,
and 16511 is equivalent to 1d2+127.
The next 4 bits (bits 7 through 10, inclusive) are used to encode the
sides of the dice. Thus, 16512 is equivalent to 1d3, and not
1d2+128.
Note that there is an implicit step-up/step-down of 2 in
the die sides encoding; 2 sides are encoded as a 0,
3 sides are encoded as a 1, and so and so forth.
To properly encode the number of sides that you want your dice to have,
follow this formula:
(define sides-encoding (* (- numsides 2) 128))
Thus 1d6 has its number of sides encoded as 512, and the
complete dice encoding is equivalent to 16896.
The next 3 bits (bits 11 through 13, inclusive) are used to encode the
number of dice. Thus, 18432 is equivalent to 2d2.
Note that there is an implicit step-up/step-down of 1 in the
number of dice encoding; a single die is encoded as a 0,
2 dice are encoded as a 1, and so on and so forth.
To properly encode the number of dice that you want your synthetic dice spec
to have, follow this formula:
(define num-encoding (* (- numdice 1) 2048))
Thus 5d2 has its number of dice encoded as 8192, and the
complete dice encoding is equivalent to 24576.
The next bit (bit 14) is the dice indicator. For positive dice specs, this
bit should be set (i.e., one should add 16384 as already discussed).
For negative dice specs, this bit should be unset (i.e., one should subtract
-16385 as already discussed).
The most significant bit is the sign bit; its interpretation by Xconq
varies depending on whether the dice representation is being treated as a
Type 1 or Type 2 dice. For Type 1 dice, the sign bit only applies to the
offset. For Type 2 dice, the sign bit applies to both the number of dice
and to the offset.
So a complete encoding of a positive dice spec is as follows:
(define dice-encoding (+ 16384 offset (* (- numsides 2) 128) (* (- numdice 1) 2048)))
For example, 3d6+5 would be encoded as follows:
(define dice-encoding (+ 16384 5 (* (- 6 2) 128) (* (- 3 1) 2048)))
A more sophisticated example, which shows the power of this method, is:
(define xp-levels (1 2 3 4 5)) (define hit-dice-levels (+ 16384 0 (* (- 6 2) 128) (* xp-levels 2048)))
The above generates five levels of hit dice; level 1 is 2d6,
level 2 is 3d6, and so on up to level 5, which is 6d6.
Encoding the parts of a negative dice spec is essentially symmetrical with
encoding the parts of a positive dice spec.
Xconq supports most of the typical Lisp arithmetic comparison operators
in GDL. In the case where only one expression is present in the comparison
form, the result is always non-nil. If any comparison fails, the
result is nil. If no comparison fails, then a true result like
Lisp's t is returned.
Function: = exp...
Test if all expressions are equal.
Function: /= exp...
Test if any expression is not equal to another one.
Function: > exp...
Test if the list of expressions is monotonically decreasing.
Function: >= exp...
Test if the list of expressions is monotonically nondecreasing.
Function: < exp...
Test if the list of expressions is monotonically increasing.
Function: <= exp...
Test if the list of expressions is monotonically nonincreasing.
Xconq supports the three primary boolean comparisons. These comparisons are used in places such scorekeepers tests. However, boolean comparisons are also used in side-and-side-class lists, and these follow special evaluations rules which do not conform to those listed below. Always pay attention to the context of the boolean expression so that you can understand its evaluation behavior.
Function: and exp...
The result is the last expression if all the operands are non-nil.
If any are false, then the result is nil.
Function: or exp...
The result is the first non-nil expression.
If all are false, then the result is nil.
Function: not exp
The result is nil, if the expression is non-nil.
Otherwise, the result is equivalent to Lisp's t.