**What is a callback?** A callback is "executable code that is passed as an argument to other code, which is expected to ''call back'' (execute) the argument at a given time" ([https://en.wikipedia.org/wiki/Callback_(computer_programming)], [http://wombat.doc.ic.ac.uk/foldoc/foldoc.cgi?query=callback&action=Search]). In some cases, as when a `-command` option is passed to `[lsort]`, the receiving command (see below) immediately executes the code (''blocking'', or ''synchronous'', callback). More commonly, a callback is specified in an `[after]`, `[bind]`, `[trace]`, I/O handler, or widget `-command` option, etc, and called when appropriate (''event-oriented'', ''deferred'', or ''asynchronous'', callback). A deferred callback must be able to execute even if the context where it was defined has since been destroyed. **Defining / expressing callbacks** In Tcl, callbacks are typically either expressions, lambda expressions, or [script]s. An expression is evaluated using `[expr]` and a lambda expression by `[apply]`. They will not be discussed further here. Callback scripts are lists of words (with wrinkles such as when one prepends a `+` character to a `bind` callback, which is part of the callback but not of the script proper). The script can be a [command prefix], i.e. a script that expects that further arguments will be concatenated to it at the point of execution, at the receiving command's discretion. **Execution** The ''receiving command'' (not a standard term) is the command with which the callback is registered. It usually executes the callback immediately or at a later time (it might in practice arrange for the callback to be executed by some other entity). When executing a callback script, the executing code will typically use something like `[eval]` or `[uplevel]` (or [Many ways to eval%|%other evaluating command%|%]), or a command substitution (`[[{*}$script]]`). It adds arguments of its own if the script is used as a command prefix, using some variation of, e.g. ====== eval $script [list $a $b] if [concat $script [list $a $b]] [{*}$script $a $b] ====== ***Name resolution*** As the script is executed, any command and variable names in the script that aren't [namespace] qualified already will get resolved to the best of the interpreter's ability. Name resolution is in itself a predictable procedure, but it is affected by dynamic conditions that might be unknown when writing the program. This makes passing a script as an argument and executing it either wonderfully versatile or frighteningly ambiguous, depending on one's point of view and how clever one tries to be. **Good practices for callback scripts** * Consider writing a command, and using the command invocation as the complete content of the script, i.e `list ?subcommand? ?argument...?`. A callback action shouldn't be too complicated to be expressed within a normal command. (In this invocation, "arguments" are those, if any, passed in to further specify the action, distinct from any arguments added by the receiver.) * If the callback ''is'' too complicated for a command, consider writing the script as the invocation of a [TclOO] method, i.e. `list ?argument...?`. * For callback scripts that depend on the namespace context of their sender, use `[namespace code]`. A script wrapped in such an invocation will be executed in the current namespace regardless of which namespace the receiver uses. * Use fully qualified names unless there is a good reason to let the name resolution procedure in the interpreter figure out the name. **Customization tricks** Spoofing a namespace capture: `namespace code` generates a script that calls `[namespace inscope]` on the namespace name and the original script. If you pass the result of `list namespace inscope