4.4.3 The Correctness of this Description
In this description of conditions in REXX, I have gone further in
the description of how conditions work, their internal data
structures, the order in which things are executed etc., than the
standard does.  I have tried to interpret the set of distinct
statements that is the documentation on condition, and design a
complete and consistent system describing how such conditions
work.  I have done this to try to clarify an area of REXX which at
first glance is very difficult and sometimes non-intuitive.

I hope that the liberties I have taken have helped describe
conditions in REXX. I do not feel that the adding of details that
I have done in any way change how conditions work, but at least I
owe the reader to list which concepts that are genuine REXX, and
which have been filled in by me to make the picture more complete.
These are not a part of the standard REXX.

·    REXX does not have anything called a standard condition.
  There just “are” a set of conditions having different attributes
  and values. Sometimes there are default values to some of the
  attributes, but still the are no default condition.

·    The terms “event” and “incident” are not used. Instead the
  term “condition” is somewhat overloaded to mean several things,
  depending on the situation. I have found it advantageous to use
  different terms for each of these concepts.

·    Standard REXX does not have condition queue, although a
  structure of such a kind is needed to handled the queuing of
  pending conditions when the trap state is DELAY.

·    The values default-action and delay-action are really non-
  existing in the Standard REXX documentation. I made them up to
  make the system more easy to explain.

·    The two-step process of first raising the flag, and then
  (possibly at a later stage) triggering the trap, is not really a
  REXX concept. Originally, REXX seems to allow implementations to
  select certain places of the interpreter where events are sought
  for. All standard conditions that can be called by method CALL,
  can be implemented by checking only at clause boundaries.

·    Consequently, a REXX implementation can choose to trigger the
  trap immediately after a condition are raised (since conditions
  are only raised immediately before the trap would trigger anyway).
  This is also the common way used in language level 3.50, when only
  method SIGNAL was implemented.

·    Unfortunately, the introduction of the state DELAY forces the
  interpreter to keep a queue of pending conditions, so there is
  nothing to gain on insisting that raising should happen
  immediately before triggering. And the picture is even more
  muddied when the NOTREADY condition is introduced. Since it
  explicitly allows raising of condition to be done during the
  clause, even though the triggering of the trap must happen (if
  method is CALL) at the end of the clause.

I really hope that these changes has made the concept of
conditions easier to understand, not harder. Please feel free to
flame me for any of these which you don’t think is representative
for REXX.



 PREV   NEXT