CMcC Two fundamental types in tcl core are Tcl_Obj and Command.
Both maintain some state, are refcounted, can be named and define some intrinsic operations.
Purposes:
The first element of a string to be evaluated must be a Command. The primary carrier of value is a Tcl_Obj.
Tcl_Obj's are arguments to and results from evaluation of Commands.
In short: Commands transform Tcl_Objs into Tcl_Objs.
Anatomy:
Tcl_Obj is typed, and provides the following operations:
Tcl_Obj provides for a string representation and an internal representation comprising storage for up to two pointers.
Command provides the following operations:
Command provides state comprising: a binding, a list of namespace import references to this command, and most importantly: client state associated with the Deletion and Evaluation operations.
Similarities and Differences:
Both can be deleted.
Tcl_Obj can be duplicated, and can mutate some other value to itself, and itself to a string.
Command can be evaluated and compiled. Since a Command is inherently named, duplication makes no sense, because duplicating a (name,value) pair is always an identity. However, rename can be considered a similar kind of function, in that it creates identical state with a new binding.
Command doesn't have a string representation, doesn't provide a Serialisation operation. This makes sense, to some extent, because its state (comprising C functions) is not meaningful as strings.
proc is the only way to transform a Tcl_Obj into a Command in vanilla tcl. itcl and xotcl provide other ways to generate Command from Tcl_Obj.
Unification:
Notwithstanding the differences between them: If a Command were represented as a Tcl_Obj, how would it look?
If we wanted to create a Tcl_ObjType which wrapped a Command, we would be trying to provide meaningful equivalence between the Tcl_Obj operations (Deletion, Duplication, Serialization, Mutation) and the Command operations (Deletion, Evaluation, Compilation)
Evaluation and Serialization seem most closely analogous, in that All Commands can be Evaluated and All Tcl_Obj can be Serialized. It may be that a CommandObj would use Tcl_Obj Serialize to Evaluate.
Command consumes Tcl_Obj arguments and generates a Tcl_Obj result, remaining (itself) unchanged, Tcl_Obj can clone itself, and can absorb (almost digest or metabolise, also shimmering) other Tcl_Objs into itself.
Most Tcl_Obj processing would be consumed in metabolising, just as most Command processing is consumed in evaluating. Both mutation and evaluation result in a transformed object (from the list of args to a result in Command, and from the object to its new form in Tcl_Obj.)
Much of the design of Tcl_Obj revolves around the need to refcount, much of the design of Command revolves around the need to bind.
RHS Fascinating information there. Let me start by saying thank you for so neatly summarizing all that information into an understandable format. There are some things, however, that I disagree with.
If we agree that we want to have unnamed commands (I use the term command to mean commands and procedures in this context), then I would define the following equivalences: