Blog » Programming Language Semiotics
Posted on 10 Feb 2009 13:20
In a recent posting to the haskell-cafe mailing list, Richard O'Keefe put his finger on a major problem that afflicts most if not all expositions of Haskell's evaluation semantics with respect to IO operations:
We need some standard terminology to distinguish between *evaluating* an expression and *performing* the result of an expression of type IO something.
This is a specific example of a more general problem with the standard idioms of programming language semantics. Traditional mathematical approaches - denotational, operational, algebraic, etc. - have one thing in common: they are purely "dyadic", to borrow a term of art from semiotics. They are founded on binary oppositions like language v. semantic domain, term v. denotation. But program texts resist such narrowly focussed conceptualizations. They have too many layers or dimensions of meaning. Terms like "evaluation" tend to be ambiguous, since they are so general.
Consider something as simple as the constant '3'. It's a symbol; it denotes a well-known, cleanly delimited value. But it also "means" a bit pattern in memory (its physical representation); that bit pattern in turn may have multiple meanings. It may be an opcode that "means" addition or some other operation on the architecture. It may be an opcode with a different meaning on another machine. It may have a different meaning for various peripheral interfaces. More importantly, it has a meaning for the author of the text. It may be used with its "standard" (i.e. mathematical) meaning, but it also may be used as an element of some kind of code; it may mean "status complete" or "account suspended" or anything else. It may mean '7', if the author is a perverse obfuscator.
With IO terms the situation is even more complicated. A term like "putChar 'c'", as Richard pointed out, is associated with at least two things: a "value" (meaning, I believe, something like closure/suspension/thunk), and an event ('a' appears on the user's screen), corresponding to evaluation and performance, respectively, to use Richard's terminology.
The fundamental problem is that the meaning of a program text involves at least three elements, not just two; it always involves an interpreter (the author, reader, execution environment, or other) in addition to the text and its denotation. In other words, we should think of programs not as dyadic denotational systems, but as communication systems involving multiple players and relations. A program is not just a denotational text; it is a sign.
Semiotics is usually defined as the study of signs, signification, communication systems, and the like. Regardless of its academic status, it provides a rich stock of concepts and terminology that should be useful for both the formal and informal descriptions of programming language meanings (I almost wrote "semantics"). In particular, its elaboration of concepts like "expression", "sign", "denotation" and the like is highly sophisticated, and accommodates the communicative aspect of such terms that a "programming semantics" approach has trouble capturing. A sign involves not just the signifier and signified, but also an "interpretant" (meaning the idea the interpreter forms about the signified, if I'm not mistaken), a code, and various other elements. It covers just about every thing a semantics approach covers - extension, intension, expression, etc. - but from a different and valuable perspective. For semiotics, a semantic system is only one component of a larger system of meaning(s).
For a simple example, we can use it to make a distinction between terms like '3' and terms like "putChar 'a'". The former has a stable, conventional denotation; that makes it a symbol in Pierce's terminology. The latter is not a symbol by this definition; it would more appropriately be called a sign, or maybe an example of a particular sign class. We could elaborate further by describing the "codes" that construct the meanings of symbols and signs. In an exposition that defines its terminology using the language of semiotics, such distinctions may turn out to help avoid the ambiguities and code-shifts common to traditional semantics-based expositions. I can't yet say for sure, but it seems like a promising approach. It even seems possible that formal modeling (as opposed to notation and exposition) might find useful structuring devices in semiotics.
To sum up, semiotics might provide a clear, structured way to talk about the many elements and relations involved in the "meaning" of a program text, with a discipline that traditional approaches often lack.
A web search on "semiotics" will find many lexicons, tutorials, etc.
Like this entry?