Jokinen refers to the technique described here as a linguistic mechanism; it is used to define hidden actions like copying, type conversions, or assigning default values to optional parameters as part of parameter transmissions resulting from various forms of procedure calls (call-by-value, call-by-reference, call-by-name, and call-by-need). The basic idea is to have a programmer think in terms of transmission mechanisms “rather than in terms of types.” These linguistic mechanisms are to be defined “within the language.” No formal definition of linguistic mechanism is given; in fact, this paper is devoid of formal definitions. From the context, it appears that the author is thinking of a compiler (rather than a language) that supports runtime type checks and dynamic binding of values to parameters. Without explanation, these linguistic mechanisms are also called “abstraction mechanisms.” The author introduces a 12-line grammar for a “fully dynamic language” to express the abstraction mechanisms, but gives no explanation of “fully dynamic language.”

Ambiguously, the syntax of the language for abstraction mechanisms is supposed to be in “semiabstract form.” A tuple [e₁,…,e_n] is said to be an ordered sequence of zero or more “data objects,” which are not defined. In fact, in the first page of this paper, the following terms are undefined: “actuals,” “data object,” “optional parameters,” “language,” “application-specific types,” “linguistic mechanism,” “parameter transmission,” “calling program” (procedure is meant), “called routine,” “abstract interface,” “abstraction mechanism,” “embedding an abstraction mechanism into languages,” and “semiabstract.” The lack of definitions of these key terms means readers will have to guess what is meant by the rest of the discussion. An environment is informally defined in English as a mapping from a finite set of strings into data objects. No explanation of “into” is given. Somehow, an environment is a “generalization of the record and package concepts.” The remainder of the paper continues in this manner: it contains informal discussions, a variety of code fragments written in the new language to define abstraction mechanisms, and implementation issues. Even though this paper was under development from 1987 until 1990, it reports that the proposed language has not been implemented.