Icon, index, symbol and denotation,

connotation, metasign

KUMIKO TANAKA-ISHII and YUICHIRO ISHII

Abstract

We discuss how Hjelmslev’s denotation, connotation, and metasign could

correspond to Peirce’s icon, index, and symbol. Our argument is based
on the application of both theories to the programming language prob-
lem of confusion as to whether a sign signifies a value, reference, or
type.

Keywords: Peirce; sign category; Hjelmslev; glossematics; type; refer-

ence; value.

1. Introduction

Semiotics has long had two sign models: the dyadic model proposed by
Saussure and the triadic model proposed by Peirce. However, the cor-
respondence between these models has always been controversial. Tra-
ditionally, it has been thought that Peirce’s interpretant corresponds to
Saussure’s signified and that Saussure’s model lacks Peirce’s object (Eco
1988; Noth 1990). In Tanaka-Ishii (2006), we raised a di¤erent hypothesis
based on semiotic analysis of the two most widely used computer pro-
gramming paradigms. We showed that Peirce’s object formally corre-
sponds to Saussure’s signified and that Saussure’s sign model is obtained
when Peirce’s interpretant is located outside of his model in the language
system. One of the major conclusions drawn from our analysis is that the
two models are compatible.
Our discussion regarding the correspondence of these two frameworks
considered only the basic level of sign models. In this paper, we go further
by trying to establish correspondence between two theories, each raised
within either the dyadic or the triadic framework.

Semiotica 166–1/4 (2007), 393–407 0037–1998/07/0166–0393

DOI 10.1515/SEM.2007.063 6 Walter de Gruyter
Brought to you by | University of Nottingham
Authenticated
Download Date | 10/31/19 3:07 PM
394 K. Tanaka-Ishii and Y. Ishii

Historically, dyadic and triadic sign models form di¤erent cultures, and
they are applied to semiotic targets independently. Discussion of any
correspondence, other than that of the sign models themselves, has been
rare. One exception is Parret, who compares Hjelmslev’s and Peirce’s
theories (Parret 1983: ch. 2). However, Parret thoroughly compares these
theories only from a philosophical viewpoint without showing any actual
correspondence between the theories.
Our belief is that if theories in either the dyadic or the triadic tradition
are genuinely relevant, then such theories should appear in some form in
both frameworks. If so, what does Peirce’s sign categorization, which is a
major result of Peirce’s work, correspond to within the dyadic frame-
work? Contrarily, which framework within the triadic model corresponds
to Hjelmslev’s connotative and metasemiotics?
Given that dyadic and triadic semiotic frameworks look totally unre-
lated, one way to tackle this problem is to find a common semiotic target
to which theories of both dyadic and triadic tradition seem to apply. As
in our previous paper, where we found a target in programming lan-
guage, we take a programming language issue as our analysis target
and see how the dyadic and triadic models apply to it. Through such
applications, we see how dyadic and triadic theories correspond to one
another.
The semiotic problem handled in this paper is as follows. In the pro-
gramming language domain, a controversial expression is often used:
x ¼ x þ 1.
First, ‘¼’ here means the action of assignment to set a value to the sign
x, not an equality in the mathematical sense. This expression is an in-
struction to update the value of x by one. For example, if x had a value
of 3 before this expression, its value will become 4 after the execution of
this expression. This kind of value updating is widely used, especially in
the imperative programming paradigm.
This simple programming expression has led to an enormous amount
of discussion among programming language designers because the sign
x on the left side does not signify the same content as the same sign
on the right side; this is not only so in terms of the value, but also
from a more semiotic aspect. Precisely, x on the right side means the
value of x (such as 3 or 4), whereas x on the left side means the refer-
ence, the memory address where the value of x is stored. Thus, this ex-
pression is executed as follows: 1. get the value stored at the memory
address labelled x; 2. add one to that value; 3. re-store the result at
the memory address labelled x. The point here is that the sign x has
di¤erent meanings within one expression: it can be either a value or a
reference.

Brought to you by | University of Nottingham

Authenticated
Download Date | 10/31/19 3:07 PM
 Icon, index, symbol 395

In analogy with natural language, this ambiguity corresponds to

whether a sign means the signifier or the signified. For example, ‘I like
the rose’ means the flower, the signified indicated by the signifier ‘rose’.
However, in an expression such as ‘Rose is a good name,’ then the sign
‘rose’ indicates the signifier. Such ambiguity cannot be resolved without
context, because a sign, either dyadic or triadic, represents several relata.
Thus, a sign is essentially ambiguous as to what it signifies among these
relata.
In this paper, we explain such ambiguity underlying the signs that
appear in the programming language domain through Hjelmslev’s
connotation/denotation-object language/metasign and Peirce’s sign cate-
gorization. Through applications, we develop a hypothesis as to how the
two theories could correspond. We start by examining the above sign
problem within programming language in more detail.

2. Semiotic confusion in computer programs

The confusion of reference and value, as in the above example of x,

is deeply related to how computers run. A computer is a state transi-
tion machine where temporary calculation results are stored in its
memory and calculation proceeds by referring to these results. These
temporarily stored results are called values and they are referred to
by indicating the respective addresses of the memory, which are called
references.
Thus, the above problem concerning x occurs at the lowest level of
description by the assembly language. Assembly language exactly reflects
how a computer runs (Rector and Alexy 1982). An example of a descrip-
tion is given here:

1: var dw 1234 ;; allocate one word memory space, name

it var, set value 1234
2: mov ax, var ;; store the value of var to ax
3: mov ax, o¤set var ;; store the address of var to ax
4: lea ax, var ;; store the address of var to ax

This program does nothing special: it just allocates one word memory
space named var and then stores its value 1234 or reference into ax, the
register i.e., special memory space used for calculation inside the CPU.

Brought to you by | University of Nottingham

Authenticated
Download Date | 10/31/19 3:07 PM
396 K. Tanaka-Ishii and Y. Ishii

Here, mov and lea show CPU operations, and var is an identifier that rep-
resents an address of the computer memory. In addition, dw and o¤set are
pseudo-operations, which indicate to the assembler software how the pro-
gram should be translated into binary machine language (so they are not
related to our discussion here).
Note that in this example, var represents two di¤erent values at the
same time:

– the value stored in the memory space named var;

– the memory address of the memory space named var.

In line 2, for example, var means the value stored at the memory space
represented as var, whereas in lines 3 and 4 var means the address of the
place. Thus, since all values are stored in memory and each memory
space has an address, a memory address can mean the address itself or
the value.
Such ambiguity cannot be resolved by looking at only the sign. It re-
quires contextual information just as with natural language. Here, the
context is

– which operation is used, (lea or mov), or

– whether the reserved word o¤set exists before the identifier.

For example, lines 2 and 3 share the operation even though var means the
value in line 2 and the reference in 3, so the existence of o¤set signifies
that line 2 means the reference.
This confusion between reference and value at the machine language
level cannot be resolved in higher-level languages, and often appears as
in the example given in the previous section.
In the expression x ¼ x þ 1, x is the identifier, just as var is in the as-
sembly language example. An identifier in programs is translated into a
memory address by the compiler software, so the same ambiguity prob-
lem arises as to whether it should be denoted as a value or a reference.
The ambiguity is resolved through the context. In the x case, the context
means the side of the assignment operation indicated by ‘¼’. The x on
the left side is called the l-value meaning that x denotes a reference,
and that on the right side is called the r-value meaning that x denotes a
value.
The same confusion occurs every time an identifier is referred to. A sig-
nificant example of this within programming languages is the contrast be-
tween call-by-reference and call-by-value, which is an important concept
that any programmer should understand. Here, we consider the following
sample program in Java (Arnold et al. 2000).

Brought to you by | University of Nottingham

Authenticated
Download Date | 10/31/19 3:07 PM
 Icon, index, symbol 397

1: void noset(int b) {
2: b ¼ 123;
3: }
4:
5: void set(int[ ] a, int i) {
6: a[i] ¼ 123;
7: }
8:
9: void test( ) {
10: int[ ] v ¼ new int[100];
11: v[0] ¼ 789; //v[0] is set to 789
12: set(v, 0); //v[0] is set to 123
13: int x ¼ 456; //x is set to 456
14: noset(x); //x is not set to 123
15: }

There are three functions: noset, set, and test. The noset function receives
b as input and sets its value to 123. This is called from line 14 of the pro-
gram, where x is handed to noset as input after its value is set as 456 in
line 13. The same action is done for the function set, which receives an
array a and sets the i th element of the array to 123. set is called at line
12, with the argument being array v whose 0 th element is previously set
to 789 in line 11. Basically, set and noset perform similar actions: both
just assign 123 to the input value.
When these functions are called, though, the result appears to be to-
tally di¤erent: v[0]’s value is set to 123, but the value of x remains un-
changed. This is because noset calls b by value, whereas set calls a by
reference. When noset is called, a new space b is allocated and the value
is copied from x, so b is initialized to the value 456. Entering the function
body, its value is reset to 123, but the original value of x will not change
because b and x are di¤erent memory spaces. On the other hand, the
value of v is the reference (memory address) of the array. When set is
called, a is newly allocated, and the value of v, the reference of the array,
is copied. Thus, a and v indicate the same content, the reference of the
array.
When the first element of array a is changed to 123, the value of array v
also changes, of course. The di¤erence is illustrated in Figure 1. The dif-
ference is again distinguished by context: this time in Java, what data
type the identifier indicates. Among programming languages, there are
typed languages and untyped languages. According to Gosling et al.

Brought to you by | University of Nottingham

Authenticated
Download Date | 10/31/19 3:07 PM
398 K. Tanaka-Ishii and Y. Ishii

(1996), types limit the values that a variable can hold or that an expres-
sion can produce, limit the operations supported by those values, and de-
termine the meaning of the operations. Thus, a type generalizes a set of
data and groups data so that they can be handled equally. Java is a typed
language; for example, an integer is a type (denoted as int), and an array
of integers is another type (denoted as int[ ]).

Figure 1. Call by value and call by reference

In Java language, it is arbitrarily defined that the values of basic data

types are stored directly at the memory place, whereas the values of com-
plex types (called object types) are stored by reference. In this example, b
is a simple integer and thus a basic type, while a is an array and thus an
object type.
Programmers should learn such language design before they start
writing programs. However, such concepts as value and reference can
be confusing because disambiguation requires a simulation of how com-
puters will run. It can sometimes even be confusing for professionals,
because what a sign indicates is not shown explicitly within the sign
itself.
So far, we have considered the sign confusion between reference
and value. Another confusion seen in programs is the confusion be-
tween type and value. The following sample program shows how this
occurs.

Brought to you by | University of Nottingham

Authenticated
Download Date | 10/31/19 3:07 PM
 Icon, index, symbol 399

1: class Dog {
2: String nm;
3: Dog(String name) {nm ¼ name;}
4: void run( ) {
5: // . . .
6: }
7: }
8:
9: void test( ) {
10: Dog jolly ¼ new Dog(‘‘Jolly’’);
11: jolly.run( );
12: }

Here, a data type Dog is defined from lines 1 to 7 and an instance is allo-
cated in line 10. The expression

Dog jolly ¼ new Dog(‘‘Jolly’’)

means to allocate a data structure of type Dog and represent it by an

identifier jolly. The leftmost Dog means that the identifier jolly is of data
type Dog, defined among lines 1 to 7, whereas the Dog of the right side
means to allocate the actual instance by calling the initialization function
defined in line 3. Thus, the sole identifier Dog could mean either type
or value, and this can only be disambiguated by context, such as by the
existence of the word new.
In natural language, the leftmost Dog corresponds to an expression
such as ‘I like dogs,’ meaning the kind of animal, whereas the rightmost
Dog means ‘I like the dog,’ with ‘the dog’ specifying a dog.
This ambiguity between type and value is less problematic than that
between reference and value, because the confusion can be easily avoided
by giving the initialization function Dog a di¤erent name. There are lan-
guages that allow this: in Ruby language (Thomas and Hunt 2000), in-
stance constructors should be named initialize, and the same expression
as above is expressed as:

jolly ¼ Dog.new(‘‘Jolly’’)

where new calls the function initialize. In Ruby, the type name Dog al-
ways meaning type. Thus, the confusion between value and type can es-
sentially be avoided. This di¤erence from the value-reference case arises
because values within computer programs are not typed; i.e., type is an

Brought to you by | University of Nottingham

Authenticated
Download Date | 10/31/19 3:07 PM
400 K. Tanaka-Ishii and Y. Ishii

abstraction seen only in higher-level programming languages. Thus, the

value-type issue depends mainly on the language design. Still, historically,
in many object-oriented language designs, type and value have acquired
the same identifier.
Even in the reference-value case, many attempts have been made within
programming design to clearly distinguish what exactly an identifier de-
notes (Meyer 2000). For example, in another language, Simula (Dahl
and Nygaard 1966; Dahl et al. 1984 [1970]), identifiers are declared as:

x : ref Dog
m; n : INTEGER;

specifying whether an identifier represents a reference or a value. How-

ever, none of these attempts have succeeded and identifiers remain con-
fusing. There are several reasons for this persistence: one is that since
addresses themselves can be values, such a distinction between reference
and value leads to more confusion; a second is that disambiguation is al-
ways possible if programmers know the language design well.

3. Application of Hjelmslev’s layered dyadic model

Such confusion is caused by a value being represented by a sign in a

stratified manner: a value is represented by a bit pattern, contained in
a memory space, which is represented by an identifier, which is typed.
Such stratified interpretation of the content fits naturally into Hjelmslev’s
framework of connotative and metasemiotics.
Hjelmslev’s glossematics is based on a dyadic sign model influenced by
Saussure. Hjelmslev renamed Saussure’s signifier and signified as, respec-
tively, expression and content. In his model, both expression and content
are stratified so as to have form, substance, and purport layers. The con-
cept of connotation/denotation and metasign becomes applicable when
pairs of expression and content are layered on top of one another.
Barthes applied Hjelmslev’s theory to actual semiotic targets (Barthes
1995). For example, he shows that mode language is four-layered (Barthes
1983: 324), consisting of meta-language, rhetoric, terminology, and cloth-
ing codes. However, Noth (Noth 1990: 310) states that Barthes’s model-
ling of Hjelmslev’s theory is ‘simplified,’ and our discussion in this section
is based on Hjelmslev’s original definition given in (Hjelmslev 1959).
Noth summarizes Hjelmslev’s connotation and metasign as follows
(Noth 1990: 71–72): Connotation is a semiotic whose expression plane

Brought to you by | University of Nottingham

Authenticated
Download Date | 10/31/19 3:07 PM
 Icon, index, symbol 401

consists of denotative elements of the language and whose content plane

consists of stylistic values. Thus, the connotators are viewed as content
for which the denotative semiotics are expression. On the other hand, the
metasign concept corresponds to the logical definition of the term as a
language about a language. Usually, the target language explained is
called the object language, following the tradition among logicians. The
metasign content part covers the object language’s expression and content
at the same time. For example, a grammar or part of speech is the meta-
sign (Noth 1990: 311) of natural language as object language.
The metasign is obtained through the abstraction of several di¤erent
signs, just as Hjelmslev denotes the metasign as ‘science’ (Hjelmslev
1959: 100–101). Given a metasign, other signs correspond to the content
plane, each of which being represented by a sign. On the other hand,
given a connotation, other signs correspond to its expression plane, each
of which has its own denotational content. Taking an example given in
(Hjelmslev 1959: 105), the two expressions ‘jealous’ and ‘green-eyed mon-
ster’ both mean jealous as content. The latter here is connotation, because
the latter has another literal meaning of a ‘monster.’
All information handled by computers ultimately consists of ones and
zeros which are represented by electric signals passing through circuits.
These bit patterns are the ultimate denotation of being inside computers.
Correspondingly, in higher-level programming languages signs that repre-
sent values only as values are denotation. For example, integers appear as
decimals such as 123 and 456. A memory address that stores these values
is a connotation of such values when the address is used to represent such
values. An address’s denotational meaning is the location inside memory,
but the address is often used as the value contained at the place. Corre-
spondingly, in a higher-level programming language, the identifier x de-
notationally represents an address and connotationally represents a value.
This multiplicity of two di¤erent expressions (denotation and connota-
tion) layered on top of one another is the source of confusion between ref-
erence and value.
This multiplicity also explains the confusion between value and type,
but this time for the metasign. The metasign corresponds to type, as type
is an abstraction of instances. Each instance acquires a name, which is
the expression at the object language level. For example, in the example
shown in the previous example,

Dog jolly ¼ new Dog(‘‘Jolly’’);

the leftmost Dog is the metasign where the expression is Dog and the
content is equal to the set of instances including a dog data named ‘Jolly.’

Brought to you by | University of Nottingham

Authenticated
Download Date | 10/31/19 3:07 PM
402 K. Tanaka-Ishii and Y. Ishii

At the object language level, the expression is jolly and content is the in-
stance allocated as Dog(‘‘Jolly’’), which denotes the actual data. Here,
again, we see that a data is multiply expressed: by denotation, then by a
connotation as object language, and then by its metasign. This require-
ment to represent a data at di¤erent levels leads to questions as to how
each expression should be designed. Java uses a solution of taking the
same expression for the metasign and the denotation.
Consequently, the correspondences could be that signs within pro-
grams that denote values only as values are denotations, references are
connotations, and types are metasigns with object-language overlapping
the connotational semiotics layer. The confusion we described in the
previous section is caused by multiple semantics lying on top of one an-
other. The detection of which layer a sign is situated on is enabled by the
context.
Related to the application of Hjelmslev’s connotative and metasemi-
otics to programming languages, there are two domains of programming
theories, each of which attempts to strictly eliminate such sign confusion
and enhance rigid semantic interpretation of programs. One is called
denotational semantics, which aims at rigidly describing the semantics of
a program in order to guarantee the program reliability. Within denota-
tional semantics, programs are transformed into another strict language
based on logic, where there is no problem of connotation. In this logical
form, a program is mathematically proven by deducing the resulting
value (Tennent 1991). The second domain is called type theory, and was
founded partly in response to Russell’s paradox. Type theory is applied to
a programming language as a ‘tractable syntactic method for proving the
absence of certain program behaviors by classifying phrases according to
the kinds of values they compute’ (Pierce 2002). Type theory analysis is
conducted totally at the meta-level of type and is realized through com-
piler type-checking tools. The meta-language and denotation levels both
handle the object language so as to aid the intermediate layer of connota-
tion as object language is handled by humans.

4. Application of Peirce’s icon, index, symbol

Unlike Hjelmslev’s theory based on dyadics, Peirce’s theory is full of tria-

dics. Peirce’s basic typology of signs is obtained by classifying each aspect
of signs in terms of a universal category, the firstness, secondness, and
thirdness (Yonemori 1981). Each aspect of representamen, object, and in-
terpretant is yet another being, so each has a possibility of being classified
by the universal category. Such a scheme gives three aspects of signs

Brought to you by | University of Nottingham

Authenticated
Download Date | 10/31/19 3:07 PM
 Icon, index, symbol 403

Table 1. Peirce’s classification of signs based on a universal category for each aspect of signs

Representation Object Interpretant

1. firstness qualisign icon rheme

2. secondness sinsign index dicisign
3. thirdness legisign symbol argument

(representamen, object, and interpretant) classified into three categories

(firstness, secondness, and thirdness) resulting in a three-by-three table as
shown in Table 1.
A sign has three aspects, each of which is classified using the uni-
versal category. Thus, a sign’s category can be represented by a triplet
(n1 , n2 , n3 ), where n1 indicates the category of representamen, n2 indicates
the category of object, and n3 indicates the category of interpretant. For
example, if we say that a sign’s category is (2; 2; 1), then this sign is
sinsign, index, rheme. Thus, a sign can theoretically be classified into
3 3 ¼ 27 types. However, Peirce added a constraint: n1 b n2 b n3 , because
the lower order being is the degenerated form of the higher order being
(CP 4.536, 5.476, 4.536, 5.475, 4.536). Therefore, there are only 10 sign
categories in total. Peirce recursively applied the same classification pro-
cess to these 10 categories, each of which he classified into three universal
categories. With the same constraint applied to (m1 , m2 , . . . , m10 ), Peirce
realized a more detailed sign typology of 66 categories. Recursively, the
same sort of process can be applied to the 66 categories and this proce-
dure could continue infinitely.
Even though such a recursive procedure is clear, the classification
of signs is often done only at the coarse level of object: icon, index, and
symbol. There are several reasons for this: that this trichotomy mostly
matches the intuitive sign classification; that no scheme exists for evaluat-
ing the correctness of the classification result; since ‘every thought is a
sign’ (CP 5.314), validation of the classification result for a sign itself is
limited; and, above all, there is no actual application where signs are
tagged according to 66 di¤erent categories. Peirce refers to the icon, in-
dex, and symbol as ‘the most fundamental division of signs’ (CP 2.275).
Here, too, to fulfill our objective stated in the first section, we will stop at
the classification level of icon, index, and symbol.
The universal category of object describes at what abstraction level the
object is referred to. Peirce’s definitions are as follows:
– An icon is ‘a sign which stands for something merely because it resem-
bles it’ (CP 3.362), ‘partaking in the characters of the object’ (CP
4.531);

Brought to you by | University of Nottingham

Authenticated
Download Date | 10/31/19 3:07 PM
404 K. Tanaka-Ishii and Y. Ishii

– An index is ‘physically connected with its object; they make an or-

ganic pair, but the interpreting mind has nothing to do with this
connection’ (CP 2.299); it is a ‘reference’ (CP 2.283);
– A symbol is a sign which ‘refers to the object that it denotes by virtue
of law, usually an association of general ideas’ (CP 2.449).
In computers, the most primitive being is ones and zeros and bit pat-
terns representing these values are icons. A bit pattern has the ultimate
resemblance to the data partaking of the object character. Similarly, signs
exclusively denoting values and instance constructors are also icons. An
index corresponds to reference, as Peirce defines, even though Peirce
placed a limit on calling indexes as a reference in cases such as demon-
strative pronouns and other limited cases (Yonemori 1981: 53). Data are
physically stored into computer memory and make an organic pair with
the index, where the memory address as the interpretation mind of the
index has nothing to do with the value. In addition, Morris referred to
Peirce’s index as ‘identifiors’ (Morris 1971 [1946]: 154, 362), where he re-
stricted the class of identifiors to spatio-temporal deixis (Noth 1990: 114).
As for symbols, a sign that embeds general ideas about values is clearly
type. The type int (integer) for the value x is the symbol.
Peirce says that the lower order signs in terms of a universal category
are the degenerated form of signs of a higher order. Applied to sign clas-
sification, this causes the confusion among signs, as the higher order
interpretation implies the lower order interpretation. A symbol has two
degeneration possibilities, into an icon or an index. The following expres-
sion clearly shows such a hierarchical representation of signs:

Dog jolly ¼ new Dog(‘‘Jolly’’);

where the leftmost Dog is a symbol, jolly is an index, and Dog on the
right side is an icon denoting the value.
Consequently, correspondences can be established that an icon is a
value, an index is a reference, and a type is a symbol. The cause of the
confusion described in section 2 is the sign of a lower order in a universal
category being the degenerated form of a higher order.
Object-oriented programming language design has never attempted to
follow Peirce’s philosophy. Rather, its history is full of trial-and-error at-
tempts to meet the requirements and needs of programmers concern-
ing language usability. Nevertheless, the languages have converged into
a form that matches Peirce’s framework as we have shown for the expres-
sion of Dog. Thus, the existence of this object-oriented programming par-
adigm appears to validate Peirce’s categorization of signs.

Brought to you by | University of Nottingham

Authenticated
Download Date | 10/31/19 3:07 PM
 Icon, index, symbol 405

5. Icon, index, symbol versus denotation, connotation, metasign

We have explained how sign classifications proposed within the dyadic

and triadic frameworks correspond to the problem raised in section 2.
From these two correspondences, when limited to this specific problem
in programming, we deduce that denotation corresponds to icon, conno-
tation corresponds to index, and metasign corresponds to symbol when
the object-language overlaps the connotation layer. These correspon-
dences are shown in table 2. If our assumption holds in general, we can
say that similar concepts were developed within both the dyadic and the
triadic frameworks, thus validating each other.
At first sight, the dyadic and triadic frameworks seem very di¤erent.
However, by combinating two dyadics in a layered manner, we obtain a
triadic relationship. At the same time, from the triadic side, a dyadic rela-
tionship is readily embedded within triadics.
In fact, Hjelmslev’s analysis of denotation/connotation and metasign
is about classifying what a sign signifies in terms of expression and con-
tent relationship. Peirce’s sign classification based on icon/index/symbol
focuses on the representamen-object relationship. Then, under our as-
sumption in (Tanaka-Ishii 2006) that Peirce’s representamen-object corre-
sponds to Saussure’s signifier-signified (and thus, Hjelmslev’s expression-
content), the two classification results should naturally correspond.
Putting these two theories together, even though the details might di¤er,
it seems that rather similar basic concepts respectively underly icon-
denotation, index-connotation, and symbol-metasign, even with the orig-
inal Peirce and Hjelmslev definitions.
When a semiotic phenomenon is described by two di¤erent explana-
tions, a question arises as to which is the better explanation. The triadic
sign tradition is better when we want to view sign levels within a sole
axis of firstness, secondness, and thirdness. The dyadic tradition is
better when the step from instance to reference to type is regarded as
two separate steps. In some senses, the dyadic framework is more flexi-
ble, because there are other possibilities for combinating two multiple
layers of denotation/connotation and the object language/meta-language

Table 2. Peirce sign classification, Hjelmslev’s connotative and metasign, and signs in
programming

Peirce icon index symbol

Signs in programming value reference type
denotation connotation
Hjelmslev
object-language metasign

Brought to you by | University of Nottingham

Authenticated
Download Date | 10/31/19 3:07 PM
406 K. Tanaka-Ishii and Y. Ishii

as Barthes did. However, if some such combinations are genuinely

important, we believe that these should also be explicable within Peirce’s
theory. In any case, our assumption is that the concepts of icon/index/
symbol and denotation/connotation-object language/metasign are com-
patible as far as applied to programming language.

6. Conclusion

Using a sign problem in programming language as an example, we have

explained how the dyadic and triadic frameworks both apply to the prob-
lem. Specifically, the problem was confusion as to whether a sign denotes
a value, reference, or type. By applying Peirce’s sign typologies and Hjelm-
slev’s connotative and meta-semiotics, we have shown how denotation/
connotation corresponds to icon/index and metasign corresponds to sym-
bol when the connotation layer is regarded as an object-language.
In the semiotic domain, use of programming language as a semiotic
target is a fairly new approach, first taken by Andersen (Andersen 1997,
1998). A related approach is semiotic analysis based on Hjelmslev’s
theory regarding mathematical notation (Herreman 2000; Marcus 2003).
Such approaches take advantage of the target semiotic system being well-
formalized and the fact that the systems are designed for humans to
manipulate. Thus, sign problems underlying the sign’s nature can be re-
viewed in a more formal manner. Our work has shared the objectives of
these pioneers and examined the correspondences among dyadic and tria-
dic models.
At the same time, the application of a theory helps to explain the phe-
nomenon in programming domain at a higher meta-level. So far, call-
by-values/references (l-values/r-values) exist without any unified view of
why such problems occur or how deeply they are related to the funda-
mental problem of sign. Interpretation through semiotics provides the
reasoning and identifies this as ambiguity problem underlying a sign —
what it signifies among its relata.

References

Andersen, P. (1997). A Theory of Computer Semiotics. Cambridge: Cambridge University

Press.
Andersen, Peter B., Hasle, Per and Brandt, Per A. (1997.) Machine semiosis. In Semiotik/
Semiotics — Ein Handbuch zu den zeichentheoretischen Grundlagen von Natur und
Kultur/A Handbook on the Sign-Theoretic Foundations of Nature and Culture, R. Posner,
K. Robering, and T. A. Sebeok (eds.), 548–571. Berlin and New York: Walter de
Gruyter.

Brought to you by | University of Nottingham

Authenticated
Download Date | 10/31/19 3:07 PM
 Icon, index, symbol 407

Arnold, K., Gosling, J. and Holmes, D. (2000). The Java Programming Language. Reading,
MA: Addison-Wesley.
Barthes, R. (1983). Système de la mode. Paris: Seuil.
— (1995). Système Semiologique. Paris: Seuil.
Dahl, O.-J. and Nygaard, K. (1966). SIMULA — an Algol-based simulation language.
Communications of the ACM 9 (9), 671–678.
Dahl, O.-J., Myrhaug, B. and Nygaard, K. (1984 [1970]). Simula 67: Common Base Lan-
guage (¼ Technical Report Publication S-22). Oslo: Norwegian Computing Center.
Eco, U. (1988). Le Signe. Histoire et analyse d’un concept, adapté de l’italien par Jean-Marie
Klinkenberg. Brussels: Editions Labor.
Gosling, J., Joy, B. and Steele, G. (1996). The Java Language Specification. Reading, MA:
Addison-Wesley.
Herreman, A. (2000). La tolpologie et ses signes. Elements pour une histoire sémiotique des
mathematiques. Paris: L’Hartmattan.
Hjelmslev, L. (1959). Omkring sprogteoriens grundlaggelse, E. Hayashi (trans.). Tokyo:
Kenkyusha.
Marcus, S. (2003). Mathematics through the glasses of Hjelmslev’s semiotics. Semiotica 145
(1/4), 235–246.
Meyer, B. (2000). Object-oriented Software Construction, 2nd ed. Upper Saddle River, NJ:
Prentice-Hall.
Morris, C. W. (1971 [1946]). Signs, Language, and Behavior. The Hague: Mouton.
Noth, W. (1990). Handbook of Semiotics. Bloomington: Indiana University Press.
Parret, H. (1983). Semiotics and Pragmatics — An evaluative comparison of conceptual
frameworks. Amsterdam: John Benjamins.
Peirce, Charles S. (1931–1966). The Collected Papers of Charles S. Peirce, 8 vols., C.
Hartshorne, P. Weiss, and A. W. Burks (eds.). Cambridge, MA: Harvard University
Press. [Reference to Peirce’s papers are designated CP followed by volume and paragraph
number.]
Pierce, B. (2002). Types and Programming Languages. Cambridge, MA: MIT Press.
Rector, R. and Alexy, G. (1982). The 8086 Book. Berkeley, CA: Osborne.
Tanaka-Ishii, K. (2006). Dyadic versus triadic sign models in functional and object-oriented
computer programming paradigms. Semiotica 158 (1/4), 213–232.
Tennent, R. (1991). Semantics of Programming Languages. Upper Saddle River, NJ: Pren-
tice Hall.
Thomas, D. and Hunt, A. (2000). Programming Ruby: The Pragmatic Programmer’s Guide.
Reading, MA: Addison-Wesley.
Yonemori, Y. (1981). Peirce no Kigogaku [Semiotics of Peirce]. Tokyo: Keiso Shobo.

Kumiko Tanaka-Ishii (b. 1969) is an Associate Professor at the University of Tokyo

[email protected]. Her research interests include computational semiotics, compu-
tational linguistics, and natural language processing. Her recent publications include ‘Dy-
adic versus triadic sign models in functional and object-oriented computer programming
paradigms’ (2006); ‘Thirdness as self-reference in computing’ (with Yuichiro Ishii, 2006);
and Text Entry Systems — Accessibility, Mobility, Universality (ed., with Scott MacKenzie,
in press).

Yuichiro Ishii (b. 1967) is a patent attorney [email protected]. His research interests in-
clude computer programming, software engineering, and legal issues in software. His recent
publications include ‘Thirdness as self-reference in computing’ (with Kumiko Tanaka-Ishii,
2006); and ‘Lambda-term and sign’ (with Kumiko Tanaka-Ishii, in press).

Brought to you by | University of Nottingham

Authenticated
Download Date | 10/31/19 3:07 PM
Brought to you by | University of Nottingham
Authenticated
Download Date | 10/31/19 3:07 PM