Well, I'd do that with "real" interpreters (using bytecode) too. But on the other hand also _especially_ for "toy" tree walking interpreters, to learn how to bu

Well, I'd do that with "real" interpreters (using bytecode) too. But on the other hand also _especially_ for "toy" tree walking interpreters, to learn how to build the pattern matching tree -- as unification is needed for the type checker anyways ;). Although I would start by reading Wadler's version (that I linked in the other post), it's IMHO a bit more accessible than Peterson's https://www.classes.cs.uchicago.edu/archive/2011/spring/22620-1/papers/pettersson92.pdf https://www.classes.cs.uchicago.edu/archive/2011/spring/2262... But please don't get me wrong: I'm just saying that there exist other, specialised and (well, generally) more performant algorithms for pattern matching and people should have at least heard about them. If somebody decides to use unification for pattern matching, that still could be changed if performance or better error messages or ... matters.