[cap-talk] How does lambda calculus influence C?
iang at systemics.com
Sat Dec 31 13:47:46 EST 2005
David Hopwood wrote:
> Ian G wrote:
>>>A person may legitimately
>>>wonder whether or not it is even possible for something so simple to
>>>provide the needed functionality. Fortunately, we have this thing
>>>called the lambda-calculus, which is at the foundation of programming
>>>langauge design, including the Java and C languages you are familiar
>>I see this as ludicrous. I don't see that anyone
>>of the C designers or the Java designers consulted
>>with lambda-calculus and it told them how to do
>>their language. What I see is that they sat and
>>thought about how other languages worked out, and
>>they built on those. The influences were prior
>>languages as far as I know.
>>It may be that you can describe all languages in
>>the sense of a particular model. But that is a
>>long way from saying that this particular model is
>>(now?) the foundation of programming language design.
> You're really quite wrong about this. Certainly the lambda calculus
> had a strong direct influence on Java.
OK, let's play the devil's advocate here, my
only choice it seems. Is it possible to
document that? Let's start with C - something
simple. What is the direct influence, and/or
foundation and/or whatever that relates lambda
calculus to C?
In later mail you said:
David Hopwood wrote:
> John Carlson wrote:
>>Same Old Stuff.
>>A YURL is same thing as a pointer, no matter whether its a method or
>>a data pointer.
> Right, and what is a pointer?
> Pointers can be most thoroughly understood by considering how they work in
> simple computational models, like the lambda calculus with local state, and
> then extending that understanding to take account of how pointers differ in
> various languages. After all, Lisp was the first programming language to
> support pointers, and Lisp is *directly* derived from the lambda calculus.
Is this the case? I submit that the first
programming language to support pointers was
assembler. In that, they are called addresses.
Which is to say, they were always there, and
they simply evolved in the direction of what
we know now.
Which takes us back to Von Neumann's characterisation
of a machine - cpu plus memory plus some other things.
To have memory, we have to have addresses, no?
Was Von Neumann thinking lambda calculus?
I'm honestly interested in this but I'm resigned
to not being satisfied by a real answer. I've
met K and R, I knew P, and worked with some of the
early commercial efforts around C - it was the
language I knew best. In all that time, I never
heard of any crossover from what you are talking
about to C. I did hear that C was meant to be
so good we'd never need to use assembler again,
which explains its desire for pointers - something
that was quite controversial at the time!
But maybe I just wasn't listening right...
Once we've covered C, what about Java? What is
this strong / direct influence? What features
did it direct? Can we show that those features
arrived because someone knew lamba-calculus and
didn't just spot them in another language and
rewrite them to fix the bugs?
Alternatively, why is Java almost like a redesigned
C++ but C++ is just a redesigned Ada in a more
convenient packaging? Which is just a redesigned
Modula 2 ... (and on and on).
> I think much of the problem with the current state of computing is that most
> people have no appreciation for history. That, and blatent unreasoning
> predjudice against anything that is perceived as too "academic" -- as if
> "academia" was some kind of dirty word, rather than the source of almost
> all useful and lasting ideas in computer system design.
The evidence of programming language design is the
languages themselves: it suggests an evolutionary
model, not a theory model. It might be plausible
to say that lambda-calculus came along at some
point and provided a useful explanation, but to
say that it is the foundation seems to ignore
what I would describe as most of the history of
computer science in preference for one particular
More information about the cap-talk