Simon Peyton Jones

I'm going to take that sequence of bytecode and compile it to a sequence of machine instructions that, when executed, will do the same thing.

Much faster.

because it can take advantage of bytecode sequences, for example, to say, you know, if you swap and then swap, it's a no-op or something like that.

So what in fact it turned out is this whole SKI business and any other, and indeed Dataflow machines also, was simply doing at runtime what you could do better at compile time.

We were building an interpreter in hardware.

So don't build the interpreter in hardware.

Instead, build a compiler that translates

your Lambda term into a sequence of machine instructions that, when executed, will behave as if you had done this reduction business.

And then you might think, well, machine instructions for what machine?

Well, from a practical point of view, it was very hard to compete with Intel, right?

They were just spending bazillions of man years on making x86s go faster.

and ARM likewise for ARMS.

So we can leverage all of that work by compiling into their instruction set.

But even if you say you are God, you are the chief executive in Intel and can tell them to add new instructions or computation mechanisms to support functional programming, what would you add?

Not very much.

Little bits to do with garbage collection barriers, I think, and such like, but nothing major.

So, in other words, I think the whole build hardware to execute functional programming directly turned out to be a mistake.

Inspiring mistake, fun mistake, I had a great time, but a mistake.

It's better to build a compiler.

And indeed, that was the data flow machine.