Newsgroups: comp.ai.philosophy
Path: cantaloupe.srv.cs.cmu.edu!das-news2.harvard.edu!news2.near.net!howland.reston.ans.net!gatech!udel!news.mathworks.com!uhog.mit.edu!grapevine.lcs.mit.edu!olivea!news.hal.COM!decwrl!netcomsv!netcom.com!vlsi_lib
From: vlsi_lib@netcom.com (Gerard Malecki)
Subject: Re: Bag the Turing test (was: Penrose and Searle)
Message-ID: <vlsi_libD0pu82.5JL@netcom.com>
Organization: VLSI Libraries Incorporated
References: <D0GFxv.5zL@gpu.utcc.utoronto.ca> <jqbD0GJ3J.BKn@netcom.com> <OZ.94Dec8233752@nexus.yorku.ca>
Date: Mon, 12 Dec 1994 20:57:37 GMT
Lines: 22

In article <OZ.94Dec8233752@nexus.yorku.ca> oz@nexus.yorku.ca (ozan s. yigit) writes:
>Jim Balter:
>
>   All you really need is a state table.
>   Current state + input utterance = response + new state.
>
>exactly so. people tend to imagine HLT exactly the way searle
>thinks it ought to be, rather than what is appropriate.
>
>oz

A lot of state machines out there are nothing more than a state
table in ROM plus storage elements for the state variables. Thus
the difference between a HLT and an actual program is a minor
hardware detail. When humans try to read off the HLT, they basically
perform the duty of the storage elements. Hence, even if the HLT is
considered static, the very act of looking it up is dynamic and 
could, in a sense, be construed as program execution.

Shankar Ramakrishnan
shankar@vlibs.com

