Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!ucsd!rutgers!mcnc!rti!ntpdvp1!kenp
From: kenp@ntpdvp1.UUCP (Ken Presting)
Newsgroups: comp.ai
Subject: Re: Some thoughts on the Searle controversy
Summary: How the semantics of programming languages determines "causal powers"
Message-ID: <617@ntpdvp1.UUCP>
Date: 1 Aug 90 16:43:26 GMT
References: <611@ntpdvp1.UUCP> <1613@oravax.UUCP>
Organization: SNA Solutions Inc., Contract Programming Group
Lines: 88

In article <1613@oravax.UUCP>, daryl@oravax.UUCP (Steven Daryl McCullough) writes:
> 
> . . .  In the first place, the semantics of the
> programming language provides what I was calling the program's
> "operational semantics". In the second place, the meaning of the data
> manipulated by the program, was what I may have called the
> "real-world" semantics of the program. . . .

This is pretty close to my position, especially in that you are drawing
a distinction between two different groups of symbols, each of which needs
a semantics.

But I don't think that the semantics of the programming language specifies
only the sequence of operations.  I think the programming language refers
to, among other things, token-types.  A token-type is (roughly) the set of
all symbol tokens of a certain shape, for example, one token-type for the
letter "O" would include all Pica-sized annular ink stains on bond paper.
(Some would say that the intention of a writer is also included in the
concept of symbol token, but I think we can omit that for now)

One aspect of the Chinese Room which nobody disputes is that Searle in the
room can read, understand, and follow the instructions of the program.  For
him to do so, the program must identify certain token-types as input cases,
actions to take, and more token-types for output.  Token-types are visible
(or audible, etc) physical events with distinctive shapes.  So as the program
tells Searle how to manipulate the symbol tokens, it is specifying a
*physical event*, with specific *causal powers*.  A Turing Machine program
has the kind of semantics - it refers to symbol tokens on the tape, state
changes, and motions.


> . . .  (As Gary Forbis points out, it
> is quite arbitrary to divide a system into "program" and "data"--- the
> data can be hard-coded into the program, and contrarily, the program
> may be created by starting with an interpreter and feeding the
> instructions in as data.)

This is a very loose way of looking at the problem, I think.  A programming
language has a definite syntax, and it is the syntax that determines which
strings of symbols are programs.  Sure, you can write a different program
that has the same I/O behavior by hardcoding some data.  But if the source
file is different, it's a different program, at least in the sense of
being a different "word" in the grammar accepted by the compiler.

Note that the compiler cannot add the semantics to the program - a compiler
is (at most) a translator, and is more likely to lose information than to
add it.  Linkers are a different story.  They certainly do add object code,
but only as instructed by the program's external symbol table.  Loaders
are more subtle, but if we consider only stand-alone programs, we can ignore
them.

> 
> What I believe about "symbol grounding" is that it doesn't happen; at
> least not in a unique way---there will *always* be more than one
> legitimate interpretation of data (either in a computer, or in a human
> brain).

The problem is not just assigning a unique meaning to the I/O symbols.
By agreeing that the programming language has a semantics which includes
references to physically identifiable events (if we still agree :-), we
have eliminated the need to specify how the program is to be "hooked up".
A computer that just reads and prints is just as "causally connected" to
the real world as an aircraft flight director.

But that's part of the problem.  I hate to use another analogy, but here
goes:  What is the difference between a computer and a numerically
controlled machine tool?  Both are programmed using a language with an
operational semantics, and both can impose an intricate pattern on a
blank workpiece (ie printer paper).  Most modern tools feature interactive
control by the machinist/operator.

We have explained how a program can logically define a physical process,
but we have not explained why we should bother to interpret the I/O data
at all!  I don't think it will do to say that we don't need to do so, the
device is still useful and worth owning.  You wouldn't want to say that
about people (at least not where your friends can hear you :-).

> 
> Daryl McCullough
> 
> P.S. Thanks for the reasonable tone of your recent postings; it seemed
> for a while that the exchanges were getting angry. Maybe it was my
> imagination.

I guess you didn't realize you were advocating slavery.  (:-)


Ken Presting   ("Machines of the world, Unite!")