A CAT  is just an untyped group of data objects.

Structurally, a CAT  is a chunk with chunk ID "CAT " containing a "contents
type" ID followed by the nested objects.  The ckSize of each contained
chunk is essentially a relative pointer to the next one.

	CAT		::= "CAT " #{ ContentsType (FORM | LIST | CAT)* }
	ContentsType    ::= ID	- a hint or an "abstract data type" ID

In reading a CAT , like any other chunk, programs must respect its ckSize
as a virtual end-of-file for reading the nested objects even if they're
malformed or truncated.

The "contents type" following the CAT 's ckSize indicates what kind of
FORMs are inside.  So a CAT of ILBMs would store "ILBM" there.  It's just
a hint. It may be used to store an "abstract data type".  A CAT could just
have blank contents ID ("    ") if it contains more than one kind of FORM.

CAT  defines only the format of the group.  The group's meaning is open to
interpretation.  This is like a list in LISP: the structure of cells is
predefined but the meaning of the contents as, say, an association list
depends on use.  If you need a group with an enforced meaning (an
"abstract datatype" or Smalltalk "subclass"), some consistency
constraints, or additional data chunks, use a composite FORM instead (Cf.
Composite FORMs).

Since a CAT  just means a concatenation of objects, CATs are rarely nested.
Programs should really merge CATs rather than nest them.