[1] We assume here that read user_read, parse, and the various printing operations are available as primitive machine operations, which is useful for our simulation, but completely unrealistic in practice. These are actually extremely complex operations. In practice, they reading and printing would be implemented using low-level input-output operations such as transferring single characters to and from a device.
Original JavaScript

To support the get-global-environment operation we define (define the-global-environment (setup-environment)) (define (get-global-environment) the-global-environment)
[2] There are other errors that we would like the interpreter to handle, but these are not so simple. See exercise 5.32.
[3] We could perform the stack initialization only after errors, but doing it in the driver loop will be convenient for monitoring the evaluator's performance, as described below.
[4]
Original JavaScript
Regrettably, this is the normal state of affairs in conventional compiler-based language systems such as C. In UNIX$^{\textrm{TM}}$   the system dumps core, and in DOS/Windows$^{\textrm{TM}}$   it becomes catatonic. The Macintosh$^{\textrm{TM}}$   displays a picture of an exploding bomb and offers you the opportunity to reboot the computer—if you're lucky. This manifests itself as, for example, a kernel panic or a blue screen of death or even a reboot. Automatic rebooting is an approach typically used on phones and tablets. Most modern operating systems do a decent job of preventing user programs from causing an entire machine to crash.
5.4.4   Running the Evaluator