Simon Peyton Jones

And its execution mechanism is SK combinator reduction.

And if you sit in MicroHS, you can ask it to show you the S's and K's that it produces.

If we had a shared screen, I could probably show you.

So long story short, then.

the SKI machine was designed to take SK trees, big trees of S's and K's and just execute them directly.

So it was built in hardware and it ran perfectly well, reasonably fast.

Now, why didn't this catch on?

Why don't we have functional programming machines?

I mean, at the time, it was a big idea.

We even had a conference called Functional Programming Computer Architecture, FPCA.

It was right there in the title of the conference.

But slowly we became aware that what was really happening is we were doing at runtime what we could do instead at compile time.

And that is always a bad idea.

Imagine an interpreter for, I don't know, Pascal or something.

Or for Java.

We can compile Java to bytecode and we could interpret the bytecode.

So then we're doing something at runtime.

At runtime, the interpreter is looking at the bytecode, saying, dispatching to say which instruction, blah, blah, blah.

Now, what does a JIT do?

It takes a sequence of bytecode and says, oh, no, no.