From newshub.ccs.yorku.ca!ists!helios.physics.utoronto.ca!news-server.ecf!news-server.csri.toronto.edu!rpi!think.com!spool.mu.edu!sol.ctr.columbia.edu!bronze!chalmers Tue Jan 21 09:27:04 EST 1992
Article 2878 of comp.ai.philosophy:
Xref: newshub.ccs.yorku.ca comp.ai.philosophy:2878 sci.philosophy.tech:1895
Path: newshub.ccs.yorku.ca!ists!helios.physics.utoronto.ca!news-server.ecf!news-server.csri.toronto.edu!rpi!think.com!spool.mu.edu!sol.ctr.columbia.edu!bronze!chalmers
>From: chalmers@bronze.ucs.indiana.edu (David Chalmers)
Newsgroups: comp.ai.philosophy,sci.philosophy.tech
Subject: Re: Causes and Reasons
Message-ID: <1992Jan18.220331.22607@bronze.ucs.indiana.edu>
Date: 18 Jan 92 22:03:31 GMT
Article-I.D.: bronze.1992Jan18.220331.22607
References: <5967@skye.ed.ac.uk> <1992Jan14.192736.24736@bronze.ucs.indiana.edu> <5994@skye.ed.ac.uk>
Organization: Indiana University
Lines: 88

In article <5994@skye.ed.ac.uk> jeff@aiai.UUCP (Jeff Dalton) writes:

>But what, exactly, counts as a correct implementation in your
>sense of the word?  Note that I don't have to rely on any steps
>being eliminated, because there are still very different ways
>to implement the program and because there is still no simple
>correspondence between variables in the source code and machine
>locations.  Just think of procedure calls, where different
>variables correspond to different stack locations at different
>times; or think of register allocation.

Obviously I don't want to spell out the whole story for a language
like C, as it would take forever.  And there are many different ways
it could be spelled out.  But very roughly, a physical system can be said
to implement a given program if there exists a correspondence between
states of the system and entities in the program such that:

(1) There's a physical property in the implementation corresponding
    to the value of every variable (i.e. a mapping F from variables and
    values to physical properties).

(2) Every "action" statement A in the program has a corresponding "action"
    F(A) in the implementation -- e.g. to the variable assignment statement
    "a:=2", there corresponds the event of the physical property F(a,2)
    coming to be satisfied.

(3) Every boolean proposition P has corresponding physical truth-conditions
    F(P); e.g. F("a=2") is F(a,2) from above; F(P or Q) is F(P)-or-F(Q), etc.

(4) (This is the most important part.)  To a conditional "if P then A
    else B" there corresponds state-transitions in the system, so that
    satifaction of F(P) causes F(A) to occur, and satisfaction of not-F(P)
    causes F(B) to occur.

Then one has to tell more complex stories about loops, procedure calls
(in particular, variables local to a procedure may have different
corresponding physical properties upon different procedure-calls),
data structures, initialization, preservation of sequential order, inputs,
outputs, and so on.  But the basics are above.

Given this, the isomorphism between causal structure of two implementations
of the same program is reasonably clear.  We simply map physical
properties in the image of F in one system to the corresponding properties
in the other, and the rules governing control structures (conditionals,
loops, etc) will guarantee an isomorphism in the structure of the causal
relations between corresponding properties.

>As an example of different ways to implement, consider that
>a functional program might be translated into combinators (no
>explicit variables left) and executed on a graph reduction
>machine, or it might be executed by an interpreter written
>in C and running on a Sun4.

Well, the above doesn't covers functional programming languages.  The
story there would be more complicated.  But it doesn't matter in any
case -- my telling the story for one programming language is enough.
Actually, the above is far more than I need -- all I really need, as
I said in the last message, is to be able to tell the story for 
Turing machines.  Even attempting to tell the story for more complicated
languages is probably a foolish move on my part, as there are so many
quibbly details to worry about.  The above formulation may have any
number of problems, given that it's off the top of my head, but the
moral is in the overall style of definition, not in the details.

>Indeed, so far as I can tell you would say a compiler that
>unrolls a loop or puts the test at the end and starts the
>loop with a transfer to the end (which happens) isn't
>"implementing" the program.

Maybe or maybe not, depending on how one spells out the details.  But it
doesn't matter.  For the purposes of my argument, we'll just limit the scope
of the argument to compilers/interpreters that satisfy my stipulations.
That will still be enough to establish a very strong "strong AI", given
that the rest of the argument goes through.  I don't need to claim that my
notion of implementation covers everything that people might want to regard
as an implementation in practice.

>Do you think a C program and an equivalent TM specify the same
>causal structure, in some sense?  

For a given causal structure that one wants to specify, one can
write a TM program that specifies it, or one can write a C program
that specifies it.

-- 
Dave Chalmers                            (dave@cogsci.indiana.edu)      
Center for Research on Concepts and Cognition, Indiana University.
"It is not the least charm of a theory that it is refutable."


