MzScheme is surprisingly complicated

I first played around with scheme a few years ago -- enough to get the hang of things like macros and continuations -- and it struck me as a very small, elegant language. But for the last couple weeks I've gotten deep into MzScheme, and I'm coming to realize that it's actually quite complicated.¹

The first thing I noticed is that once you go beyond syntax-rules, macros start getting quite involved. There's syntax objects (because s-exps can't store all the info you want to keep track of), certificates (which address subtle interactions between macros and modules), rename transformers, the ability to overload function application, the ability to inspect the lexical scope of the call site, and more.

Then I came across continuation marks, which I don't really understand the need for, other than taking the documentation's word for it that they're important for error reporting and debugging.

Next up was custodians. The nearest analogue that I know of from other programming languages is Java's SecurityManager, except that MzScheme already has "security guards" for that. A custodian is more like a cross between a subshell and the unix quota command -- it can kill a whole batch of things all at once, and it can restrict their total memory usage, as well.

[1]: My motivation for digging into MzScheme is that I'm trying to get familiar with the FrTime code, which implements a scheme-like language with data-driven dataflow semantics. Because it's based on MzScheme, and because the language it implements is more or less a superset of scheme, understanding FrTime requires understanding many of the nitty-gritty details of how MzScheme works.