The Pd patch looks more complex than the C code. One possible reason for the complexity is the difficulty of sequencing actions in Pd patches, which lack the natural sequentiality of a text programming language like C. Another is the relative lack of names; only three names (other than Pd class and message names) appear in the patch (``n", ``struct1", and ``h"), compared to eight in the C code (``thelist", ``n", ``ptr", ``count", ``c_next", ``c_whichclass", ``CLASS1", and ``c1_h"). Of these, two of the Pd names (``n", and ``pd-list") might be considered to act as variables, compared to four of the C names.
The complexity of the patch needed to accomplish this task might be reduced
somewhat if either the value and/or expr objects were extended to
deal with pointers. For instance, a ``value ptr" object (unsupported in the
current version of Pd) could hold the output of the first pointer object
in readiness for the incrementing step at bottom. So far, though, mockups
using features such as this have not been observed to reduce the number of
objects and lines in patches equivalent to the one shown here.
The expr object could conceivably handle data structures and slots with
the addition of a few C-like constructs, and could also be fixed to set and
retrieve the contents of value-style variables. This would cause the
Pd and Max versions of expr to deviate from one another (they currently
share the same code, maintained by Shahrokh Yadegari [Yad03]).
In general, it seems problematic to lean in too fundamental a way on expr
as the fundamental mechanism for getting and retrieving data.
On a more general plane, the relationship between the data and the code that accesses it is the same in Pd as it is in C. One wishes that the functionality could somehow reference the look and feel of the data themselves, or possibly even be built into the template patch (as methods go with class definitions in C++.) So far no model has emerged that accomplishes this smoothly.
Another aspect of the question, not touched on in this paper, is the utility
of somehow catching user operation (with mouse and keyboard, perhaps among other
ways) with the graphical data. There should be a way to provide hooks to data
when certain operations are carried out on them. Perhaps this should be
realized as a way of fielding Pd messages (via pointer objects?) sent
to objects to get or set their state.
The data structure accessor objects could easily be back-compatibly replaced or augmented with others if a clean design can be found for getting and setting the data. This ``data" feature was the original motivating force behind Pd's design; it is interesting that it now appears likely to be the last aspect of Pd to be defined.