Suggested new introduction to section 3 and subsection 3.1
of the manual. To begin with, the introductory text, titled
"References", seems to be an introduction to the entire chapter,
not just to part 3.1. You may want to separate this, either by
an "introduction" section (as in chapter 2, although in my
opinion it looks a bit unneccessary to have a separate, three
lines long, subsection 2.1, instead of just these lines without
heading); or you may e.g. write


 (3)
 This chapter contains more formal, but also more complete
descriptions of the user available procedures and variables,
and choices of modes of operation. You may use it for
references. Since some of the alternatives were not mentioned
before, it may also be valuable to glance through e.g.\
the entire section~3.1, although part of the information may
not seem to be very clear at a first reading.


 3.1 Mode handling

 There are a large number of choices of modes of operations in
bergman. In this section, we list all of them, with brief (but
sometimes not quite complete) descriptions of their impacts.
All such chosen modes together form the {\sl setup}.

 The large number of possibilities may be good for flexibility,
but it also may be a bit hard to survey and handle in an easy
manner. For this reason, bergman provides three principal ways
to handle mode settings: By the shell interface, by individual
mode changing procedures, and by handling entire setups
directly as objects in their own right.

If you use the shell interface, the most convenient way to
inspect and change mode settings is by employing the
corresponding interface item. The shell choices are essentially
organised in the same tree-like manner as the mode setup as
described in this section, and you should have no trouble to
find the manual description corresponding to a shell choice, or
vice versa.

 (There is also an experimental and incomplete `dialogue'
interface, which is intended to have similar properties.)

Each individual major or minor mode change may be achieved by
calling a mode changing procedure. In fact, often there are
alternative such procedures; e.g., one for a specific mode
change effect, and one more general, where the arguments provided
by the user will decide the effect. In the latter case, giving
the argument "help" often yields a list of all legal alternatives,
followed by a prompt for inputting one of them.

Finally, the whole mode setup may be represented by a lisp object,
which may be inspected, saved, changed, checked for consistency,
and put into simultaneous effect. The latter is achieved by means
of the procedure PUTSETUP, which also may be given just a partial
setup as argument, effecting a single or a group of single mode
changes. We call this approach `the compact mode handler'.

\medskip
It is worth to repeat, that there is no essential difference
between these three ways to change modes. Internally, the shell
employs the compact mode handler, which in its turn employs the
individual mode setting procedures. The user thus may learn one
way to handle this, and safely forget all about the others.

Internally, a mode change normally consists of two parts: a
change of some procedure definitions, and a reassignment of the
value of some variable or switch. The procedure definition changes
employs the fact that Lisp automatically has an element of
indirection in its function calls, even from within compiled
procedures (excepting macros or inlined procedures). Thus, in
time sensitive parts of the programme, a change of procedure
definitions offers flexibility at no run time cost. Instead,
the price is paid by the programmer, who has to define a
multitude of variants for the same procedure, and keep track of
which one of the function definition is to be `copied' (which
mostly essentially means `linked', but sometimes even may mean
`recompiled') in a specific situation.

\medskip
Finally, one word of warning to the practioned Lisp or Reduce
programmer: You may view the source code, and help yourself to
customised deep level changes, as you wish. When you do, you'll
soon find out which switches (identifiers starting with an asterisk)
are accompanied to which mode choices. If you wish, you may
access them for direct information on the current mode setting
(always running the risk that these internal names are changed in
the next bergman version, of course). However, do not use them for
achieving mode changes! For a Reduce user or programmer, it is
natural to change switches by means of the procedures ON and OFF.
However, if you do, you miss the rather essential other part of
the mode change: the procedure redefinitions.

One example: In the present version, the switch associated with
the choice of commutativity or noncommutativity has a name like
*#NonCommutativity#, or in the `inverted case' implementations,
*#nONcOMMUTATIVITY#. You may turn on this directly, in order to
fool a few procedures that actually look at the value of the
switch to behave as if you were in noncommutative mode. However,
the actual mode change performed by the procedure NONCOMMIFY
essentially consists of more than twenty procedure redefinitions,
which you miss by just changing the switch value. Thus, if you
run your own variant, with this switch changed instead of the
mode changed in a proper manner, you are apt to run into rather
queer and unpredictable difficulties - and we will not be
inclined to help you to entangle this mess.
