You can enable error trapping via the -e command line option at kdb start-up:

$ q -e 1

or from the q console

q)\e 1

Upon an error, kdb halts and outputs the body of the function (.z.s (self)) in which the error occurred as well as an error message. You are free to inspect the values of any global or local variables to try to diagnose the source of the problem. At this point you have the following options:

  • type (single quote) to pop the stack.
  • type :(colon) to resume execution
  • type \(slash) to exit debug mode

There is no ability step into a function call or move up and down the stack.

The q language has only 3 non-atomic data structures:

  • lists
  • dictionaries
  • tables

However, q does use other structures internally (e.g., hash tables) to enhance the performance of operations on the above language-level structures.

Semantically, q is pass-by-value. However, q only copies values of structures (i.e., lists, dictionaries, or tables) if they are modified by the callee, so q often performs as well as pass-by-reference.

What do you do if you want to have the callee modify variables passed by the caller? As our reader cyprus points out, you can pass the name of a global variable:

modifier: {[variable_name]
variable_name set 47;
}
caller: {[]
global:: "global";
modifier `global;
show global; // prints 47
}

Whether this should be called pass-by-reference is the subject of many flame wars; Wikipedia’s entry on Evaluation strategy provides a cogent, balanced explanation of the varying interpretations of that (and related) terms. What’s important to know are the following:

  • it is impossible for a callee to modify a caller’s local variables, and
  • passing a large structure between functions is inexpensive until a callee modifies it.