Workspace restore reverts both code and data, preventing selective code rollback

Answer to the question

APL’s )SAVE command captures the entire workspace – functions, variables, and data – so a restore will always roll back both code and data. APL itself offers no built‑in mechanism to isolate the two. The usual solution is to keep the source code in an external version‑control system (e.g. Git) and load it into the workspace at runtime with )LOAD, while keeping data in a separate namespace or in a file that is linked via )LINK / )SALT. This allows a “code‑only” rollback without touching the latest data.

Why a full restore reverts everything

• )SAVE writes a snapshot of the entire environment to disk.
• Restoring that snapshot replaces the current workspace state wholesale.
• There is no flag or option to exclude variables or to keep a live data set.

Recommended practice for code‑only rollback

1. Store all function definitions in separate *.apl files or component files under version control.
2. Keep data in its own namespace (e.g., DATA::) or in a file that is linked with )LINK / )SALT.
3. When a code change needs to be rolled back, clear the logic namespace with )CLEAR and load the desired version with )LOAD.
   • Example: )CLEAR LOGIC:: then )LOAD 'v1.3_logic.apl'.
4. After loading, the data namespace remains untouched, so the most recent data values persist.

Using component files to isolate data

Component files can be used to separate code from data by keeping data in a dedicated component that is never touched by the )LOAD of the logic component. The runtime workspace then only loads the logic component, leaving the data component as a persistent reference.

Tooling and conventions

• External version control (Git, Mercurial, etc.) – keeps code history independent of runtime state.
• Bootstrap script – a small APL script that clears the logic namespace, loads the latest code, and re‑establishes links to the data component.
• Namespace naming – conventionally use CODE:: and DATA:: to make intent clear.
• Link/SALT files – store large data sets in external files and link them once; they survive workspace resets.

What’s still uncertain?

Whether the data you need to preserve is purely in‑memory or stored in a file that might be modified by other processes affects how safe this approach is. If the data lives in an external file, you must ensure that the file is not overwritten by a workspace reset or by other APL sessions.

Question for you

Do you currently keep the data you want to preserve in an in‑memory namespace or in a file that you link with )LINK / )SALT? Knowing this will help refine whether a simple )LOAD‑based rollback is safe for your workflow.