如何不使用全局变量以函数式风格实现数据追加？

Great question—using global variables like res for incremental appends is a common imperative approach, but it breaks functional programming principles (side effects, mutable state) and can lead to bugs if the global isn’t properly reset between runs. Here are a few clean, functional alternatives that don’t rely on globals:

1. Generate All Sub-Tables First, Then Concatenate #

This is the most straightforward functional approach. Instead of appending to a global incrementally, compute all your required sub-tables first with each, then combine them into a single table in one go.

Example: #

// Your list of variables to query against
someVarsList: 10 20 30;

// Create a list of tables, one for each variable
subTables: {select x from y where z = x} each someVarsList;

// Combine all tables into one. Use `raze` if all sub-tables have identical schema:
finalResult: raze subTables;

// Or use `,/` (folded union) to explicitly handle empty cases:
emptySchema: ([] x:()); // Match the schema of your select output
finalResult: ,/[emptySchema; subTables];

This method is often more efficient than incremental appends because q optimizes batch concatenation. It also eliminates the risk of leftover data from previous runs (since there’s no global state to clean up).

2. Use a Fold with a Local Accumulator #

If you prefer an incremental approach but still want to avoid globals, use ,/ to fold over your variable list with a local accumulator (an empty table of the correct schema). All state stays contained within the fold operation—no external mutations.

Example: #

someVarsList: 10 20 30;
emptySchema: ([] x:());

// Fold over the list, appending each sub-table to the accumulator
finalResult: {[acc; var] acc, select x from y where z = var} /[emptySchema; someVarsList];

This mimics your original logic but keeps everything self-contained. The accumulator starts empty, and each iteration adds a new sub-table—no global variable required.

3. Wrap in a Pure Function #

For full reusability and testability, wrap the logic in a pure function that takes your variable list as input and returns the combined table. This ensures no side effects and makes the code easy to integrate into larger pipelines.

Example: #

getCombinedData: {[vars] 
    // Generate sub-tables and concatenate
    ,/ {select x from y where z = x} each vars
};

// Usage:
finalResult: getCombinedData[10 20 30];

Key Benefits of These Approaches: #

• No side effects: None of these methods mutate external state, so your code is safer in concurrent environments or when rerunning scripts.
• Clearer intent: The functional approach makes it obvious you’re combining results from multiple queries, rather than incrementally modifying a global.
• Error safety: If sub-tables have mismatched schemas, raze or ,/ will throw an error immediately, catching inconsistencies early (whereas the global approach might silently append invalid data).

内容的提问来源于stack exchange，提问作者delita