CPS transforms are not the only way; if you translate the scheme to bytecode for a virtual machine, the call stack and IP can be reified.

But yes, for a compiler specifically, you need a CPS transformation

CPS transformation is a good thing to do anyway, no? Then CPS your CPS and you have delimited continuations.

As far as compiling continuations goes, sequent calculus (specifically as a compiler IR) is an interesting research direction. See Grokking the Sequent Calculus (Functional Pearl) from ICFP 2024: https://dl.acm.org/doi/abs/10.1145/3674639

"This becomes clearer with an example: When we want to evaluate the expression (2 + 3) ∗ 5, we first have to focus on the subexpression 2 + 3 and evaluate it to its result 5. The remainder of the program, which will run after we have finished the evaluation, can be represented with the evaluation context □ ∗ 5. We cannot bind an evaluation context like □ ∗ 5 to a variable in the lambda calculus, but in the λμ~μ-calculus we can bind such evaluation contexts to covariables. Furthermore, the μ-operator gives direct access to the evaluation context in which the expression is currently evaluated.

Having such direct access to the evaluation context is not always necessary for a programmer who wants to write an application, but it is often important for compiler implementors who write optimizations to make programs run faster. One solution that compiler writers use to represent evaluation contexts in the lambda calculus is called continuation-passing style. In continuation-passing style, an evaluation context like □ ∗ 5 is represented as a function λ x . x ∗ 5. This solution works, but the resulting types which are used to type a program in this style are arguably hard to understand. Being able to easily inspect these types can be very valuable, especially for intermediate representations, where terms tend to look complex. The promise of the λμ~μ-calculus is to provide the expressive power of programs in continuation-passing style without having to deal with the type-acrobatics that are usually associated with it."

A brief summary of the SC-as-a-compiler-IR vs. CPS from one of the authors of the paper: https://types.pl/@davidb/115186178751455630

"In some sense the Sequent Calculus (SC) is quite similar to a CPS based IR. To sum up the benefits of SC over CPS in two concepts, I would say: Symmetry and non-opaque continuations.

Symmetry: A lot of pairs of dual concepts are modelled very naturally and symmetrically in SC: call-by-value and call-by-name, data types and codata types, exception based error handling and Result-type error handling, for example.

Non-Opaque continuations: Instead of continuations in CPS which are just a special kind of function whose internals cannot be inspected (easily), SC introduces consumers whose internal structure can be inspected easily, for example when writing optimization passes."

It's not true that you need to use CPS to implemented first-class continuations. There are plenty of slow ways to do it, and even if you want to be fast you can do multiple different things. Dybvig describes a number of options in his thesis: https://www.cs.unc.edu/xcms/wpfiles/dissertations/dybvig.pdf

Very true but the other side of this is first class continuations are no worse than compiling try-catch semantics, and hygienic macros are still just macros so the complexity is kept simple (sort of. maybe simple isn't always so simple).

The other thing that makes languages like scheme difficult to compile are those closures. In fact, the book, the implementation of functional programming languages, Jones (1987) didn't do it at all! No closure conversion at all. They just compiled to a letrec in the g-machine.

Use someone else's implementation of the macro stuff and focus on the compiler.

Slides author here. Thanks for flagging that. I'll fix it before I give the talk again, most likely in 2044 :)

Thanks for the heads up.