An atomic scope is the period of time during which local variables live. At the beginning of an atomic scope there are no local variables, and at the end of that atomic scope, all local variables are destroyed. Thus, the atomic scope defines the availability and lifetime of a local variable.

When the client starts up, it creates a global atomic scope that lives for the entire lifetime of the client. Thus it is always possible to create local variables, even from the input prompt.

From time to time (see the list below), the client creates new atomic scopes. When a new atomic scope is created, any local variables that were visible in the previous atomic scope are hidden and can no longer be accessed! The client arranges for this by using a stack. Each atomic scope can see only those local variables on its position in the stack.

Eventually an atomic scope ends, and then its local variables are destroyed. They cannot be recovered once the atomic scope ends. Because the scopes are stored as a stack, atomic scopes are destroyed in a strict Last-In-First-Out order.

• Commands executed by defer
• Files loaded by the pf loader
• exec -line, -error, or -end callbacks
• Commands executed by wait -cmd
• User-created keybinding callbacks
• Commands executed by queue
• Commands executed by timer
• User-created set callbacks
• Who -line or -end callbacks
• Ison -oncmd, -offcmd, or -end callbacks
• Userhost -cmd callbacks
• ON callback bodies
• Each time an alias is executed

[future expansion]

Local variables first appeared in EPIC4pre0.009