Make debugger traces less confusing (and other low hanging fruit)

[roberth]

Is your feature request related to a problem? Please describe.

The debugger has commands for two types of "traces".

• :bt, which aligns with the call stack
• :st, which shows the scope

I wouldn't think of the latter as a "trace" but rather just the scope.
Nonetheless, :st <num> selects from the :bt stack. I suppose the reasoning is that it switches the repl scope to a different call stack frame.

Describe the solution you'd like

Add :scope (and not :scope <num>). It behaves like :st. Hide :st and make it tell you to use :scope.

Add :frame <num> to select a scope from the backtrace. This matches GDB. (LLDB has frame select <num>.)

:bt is good and aligns with GDB and LLDB.

Maybe add a :scope <num> command for the purpose of accessing shadowed variables, or something more explicit like :scope leave <num>.

Clean up and clarify the :? help text.

Review the output printed by the commands. Some terms don't match well with the user's frame of reference; e.g. "Env level" -> "Scope level", and "static:" seems irrelevant. Drop the printed pointers?

Reverse the print order of the call stack (:bt), to match the order of --show-trace. (ie without changing the frame<->number mapping. 0 is still the latest frame, but will be printed last)

Describe alternatives you've considered

Not so much an alternative, but alternative naming can be considered.

Maybe make it more noun-verb like, like the CLI. Feels more LLDB-like, although hopefully more consistent.

:bt
:frame select 2
:scope
:scope select 2

Doesn't feel like a big difference though, and more effort to type that in.

Additional context

Priorities

Add 👍 to issues you find important.

[kjeremy]

It would be nice if the definition of callstack and scope were somewhere easily discoverable as well. It is not obvious what the difference is.

[roberth]

Yes, those should be in the glossary.

In (too) few words I would say, given a subexpression,

• The scope is a property of any subexpression, the set of all variables that can be referenced from that location in the file. The set of names can be determined from the file alone by traversing all parent expressions and then adding the builtins.
• The callstack arises from the nesting of function calls (and some other evaluation steps). As one function calls another, both functions' scopes exist simultaneously, until the called function has produced a result. Many calls form a chain, which is only extended or shortened on one end, hence "stack".

Does that help or is it too heavy on jargon?

I hope we can collectively forget that scopes happen to form a stack, as implemented, because that stack is really just the sequence of parents (ancestors) in the abstract syntax tree. We can stick to "sets of variables", and syntax tree terminology for those.

[tomberek]

Can be worked on as it would improve the UX, but needs some additional design and clarification. Overhaul of REPL commands is a change that can cause disruption so we should minimize how often we do it (as noted: it may need warnings, notes, deprecation, etc).

At the moment the Nix team does not plan to prioritize this.

[nixos-discourse]

This issue has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/2023-04-08-nix-team-meeting-136/42963/1