[btilly]

SCIP winds up making sure that you understand what is going on by writing Scheme interpreter in Scheme. How would your translation handle that material?

Writing a Scheme interpreter in Python would force people to learn all of that Scheme anyways, and it wouldn't feel like such a revelation that you understand what the interpreter is actually doing.

Writing a Python interpreter in Python would force people to learn a lot more about parsing techniques. That would add a lot more material, and the code would be substantially more complex, thereby obscuring the pedagogical point.

[naughtysriram]

Why not write a python(subset) interpreter in scheme?

The point is once you scan,tokenize and parse you get an AST. You already got a language that works on AST. I don't think python's AST is gonna differ a lot from scheme's.

[btilly]

The problem is that Python's AST looks different than Python. In Scheme there is no such intermediate step.

They don't write a scheme(subset) interpreter in scheme. They write a scheme interpreter in scheme.

[zephyrfalcon]

Um, yes, actually they differ a lot. In Scheme (and Lisp in general) the code pretty much is the AST. This is not the case for Python.

[btilly]

I think that the point was that the AST for a Scheme program isn't that different from the AST for a Python program, even though the code looks different.

Unfortunately that point is false as well. The AST for a Python program will generally involve a lot of message dispatches that won't exist in the AST for a similar Scheme program.

To get a sense of the difference, in Python if you yield, your code actually gets turned into a class with certain methods that get called repeatedly, and restart your method at the correct place with the correct state. By contrast equivalent code in Scheme will somewhere under the hood have call-with-current-continuation, which works by very different mechanics.