self-replicating-code, self-replicating-messages

[alti%tub-tfs.uucp%TUB.BITNET@MITVMA.MIT.EDU (Thorsten Altenkirch)]

> I think you are confusing the phenomenon of reduction to normal form
> in the lambda calculus with the process of evaluation which takes
> place in the case of a Scheme program yielding a value.

Sorry, I haven't been clear here. There is a strong analogy between
reduction and evaluation, but it's not the same thing. For me the
lambda calculus serves as a principial model of functional languages,
which can be used to understand certain aspects of these languages
without the overload of accidential properties of implementations. So
evaluation relates to reduction and values to normal forms.

There are functional languages which use reduction as evaluation.
MIRANDA is such an example, it uses a reduction machine for lazy
evaluation. See the book of Simon L. Peyton Jones ("The implementation
of functional programming languages", Prentice/Hall, 1988) for how
lazy functional languages are implemented by reduction machines.

> E.g., the result of the program (list 'list 8) is (list 8), *not* (8),
> which would have been the case in the case of continual reduction.

I think the relation between normal forms and values is, that normal
forms somehow denotate values. The point that lisp values can be lisp
programs again is - as important it is for programming practice - only
confusing here.

> >(define (yy y f x) ((f ((y y) f)) x))
> >(define y (yy yy))

> You doubtless imply currying, viz.,
> (define yy (lambda (y) (lambda (f) (lambda (x) ((f ((y y) f)) x)))))

I am sorry, somehow I copied the old version of the function into my
buffer. I imply nothing it's just a mistake - your version is the
correct one.

Thank you for your comments . . .

Until now nobody has answered my other question (mailing list for
theoretical questions of functional programming).

Thorsten