Although the public include files provided by Elk can be used by C++ code, Elk itself cannot be compiled with a C++ compiler. The interpreter has been written in C to maximize portability.
 Because of a limitation in the C language, primitives of type EVAL can only have a fixed maximum number of arguments (currently 10). If more arguments are required, VARARGS must be used instead.
 Elk actually employs two garbage collectors, one based on the traditional stop-and-copy strategy, and a generational, incremental garbage collector which is less disruptive but not supported on all platforms.
 The problem of managing an ``exact root set'' can be avoided by a technique called conservative garbage collection. A conservative garbage collector treats the data segment, stack, and registers of the running program as ambiguous roots. If the set of ambiguous roots is a superset of the actual roots, then a pointer that looks like a heap pointer can safely be considered as pointing to an accessible object that cannot be reclaimed. At the time Elk was designed, conservative GC was still in its infancy and sufficient experience did not exist. For this reason, and because of the implied risks on certain machine architectures, the inherent portability problems, and the inability to precisely determine the actual memory utilization, a traditional GC strategy was chosen for Elk.
 This interface has evolved in a slightly ad hoc way; the two-stage relationship expressed by groups and group leaders may not be sufficient for more complex hierarchies than those used in X.
 Fortunately, with the advent of multithreading, vendors are now beginning to provide reentrant versions of their system libraries.