Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!bloom-beacon!MITVMA.MIT.EDU!STCS8004%IRUCCVAX.UCC.IE
From: STCS8004%IRUCCVAX.UCC.IE@MITVMA.MIT.EDU ("G.OULSNAM")
Newsgroups: comp.lang.scheme
Subject: Self-reproducing code (correction)
Message-ID: <8810121658.AA20311@BLOOM-BEACON.MIT.EDU>
Date: 12 Oct 88 16:35:00 GMT
Sender: daemon@bloom-beacon.MIT.EDU
Organization: The Internet
Lines: 24

My thanks  to John Gateley for  pointing out the erroneous  claim regarding
the normal order/applicative order evaluation of ((lambda (x) (x x) (lambda
(x) (x x)). I'm  sorry he chose not to examine the  rest of the derivation,
as  it did  not rely  on the  erroneous claim.  For the  record, what I now
consider I should have written was:

"Consider
                  ((lambda (x) (x x)) (lambda (x) (x x))).

With normal order  evaluation this reproduces itself, but  loops forever on
attempting  to  evaluate  the  result.  However,  in Scheme  the
argument  is evaluated  to an  internal procedure,  say #<procedure>, which
then  loops  forever  trying  to  evaluate  the  first  (x  x) in the above
expression, without reproducing the original form directly."

The remark  about Scheme applies to  TI Scheme (v2), and  can be checked by
depositing extra code to see what is being passed around. My point was, and
remains, that both normal order  and applicative order (by-value in Scheme)
cause the above  to loop, but for different  reasons. Normal order provided
the  idea for  self-reproducing code,  if  one  could first  find a  way to
emulate normal order evaluation, and then  find a way to stop evaluation of
the result.  The remainder of the article showed how.

Gordon Oulsnam.