[PDP-10 Only] A hunk is a first class, composite data object similar in many ways to a cons-cell. Where conses can only hold two objects (a car and cdr), however, hunks can generally hold more.

Hunks come in a variety of types: HUNK2 , HUNK4 , HUNK8 , HUNK16 , HUNK32 , HUNK64 , HUNK128 , HUNK256 , and HUNK512 . Although a hunk of any size up to 512 may be created, it will always be built out of one of these standard types. As might be expected, a HUNK2 takes exactly 1 word of storage, a HUNK4 takes exactly 2, and so on.

The number of active slots in a hunk is called the hunksize of a hunk. No primitives are provided for adjusting the hunksize of an already-consed hunk. A 5-length hunk would be created in HUNK8 space, taking exactly 4 words of storage. The HUNKSIZE primitive on such a hunk will return 5, even though its datatype (as returned by TYPEP ) is HUNK8 . A 6 or 7-length hunk would also be allocated storage in HUNK8 space and would take up the same amount of room. The unused slots in an odd-length hunk go to waste.

There is a special predicate, HUNKP , which responds T for objects whose datatype is one of the hunk types.

A slot in a hunk is called a cxr (pronounced “COOK-sir”). A particular cxr of a hunk is addressed by a single fixnum index.

Hunks also have a read/print syntax similar to that of lists. A hunk is displayed with parentheses bounding it and a dot after every element. e.g., (A .) , (A . B .) , (A . B . C .) are valid printed representations. The order of display of hunk slots is historical in nature. For better or worse, the elements of a hunk display in order except that the 0th element is last, not first. e.g., for a hunk of a length n+1, (cxr1 . cxr2 . ... . cxrn . cxr0 .) . Whether or not this syntax is accepted by the reader is controlled by the variable MAKHUNK -- by default it is accepted by the reader. The functions CAR and CDR are defined on hunks, though the meaning of such operations may be less than intuitive. In particular, ( CAR hunk) is the same as ( CXR 1 hunk) . ( CDR hunk) is the same as ( CXR 0 hunk) . The remaining elements of a hunk, those not addressable by CAR and CDR , are sometimes called the middle of the hunk, because they appear in the middle of the printed representation. Note also that CAR extracts the leftmost element of a hunk, just as it addresses the leftmost element of a cons. Similarly, CDR extracts the rightmost element of hunks and conses.

The cdr of a hunk can also be its plist. Since all hunks have a cxr-0 slot, all hunks have a plist. (Note that the operation CAR is undefined on hunk-1's, but CDR is not.) This means that if you want to make a plist for a hunk of your own, you can use its cdr as a hunk; it does not mean that you can blindly assume that any hunk wants its CDR treated that way. The exact use of the slots of a hunk is up to the creator; it's a good idea to mark your hunks (e.g., by placing a distinctive object in their cxr-1 slot) so that you can tell them from hunks created by other programs.

Like lists, hunks may be inhomogeneous collections of data. Any hunk slot may contain an object of any datatype.

Certain hunks can be made to be treated specially by various aspects of the Maclisp system in order to implement the extended datatypes. This section deals only with general information about hunks. Magic incantations for making hunks behave like extended datatypes will be discussed elsewhere.