evaluation is order dependent in local scope (missing attribute)

[ahkinsat]

Bug: Lambda evaluation only computes last field when depending on local variables

Disclaimer: This issue is the result of human-AI collaboration after searching for the bug cause . I indeed experienced and reproduced the error and provided the code(partially the file is long and contains bunch of colors). The analysis down below was primarily generated by an LLM (DeepSeek) and is speculative - the author does not fully understand the codebase and this analysis may be incorrect. Please verify independently.

Description

When defining a lambda that creates a config object with multiple computed fields depending on local variables (defined in the same lambda), only the last field in declaration order appears in the output. Earlier fields are missing entirely.

This works correctly in global scope but fails in lambda/local scope.

Reproduction

# some types and schemas like Palette
...
# Base data structure (validated as correct YAML was indeed output)
everforest_src = {
	light = {
		fg = {...}, 
		bg = {
			hard = {...}, 
			..other variants
		}
	}, 
	dark = {..similar to light mode}
}  # Schema-validated theme, no errors

# ✅ WORKS - Global scope
_mode = "light"
_variant = "hard"
everforest_light_hard = {
    mode = _mode
    variant = _variant
    fg = everforest_src[mode].fg
    bg = everforest_src[mode].bg[variant]
}
# Result: {mode="light", variant="hard", fg=..., bg=...} - both fields present

# ❌ FAILS - Lambda scope (fg first, bg last)
get_palette2 = lambda _src, _mode, _variant -> {
    mode = _mode
    variant = _variant
    fg = everforest_src[mode].fg
    bg = everforest_src[mode].bg[variant]
}
everforest_light_hard2 = get_palette2(everforest_src, "light", "hard")
# Result: {mode="light", variant="hard", bg=...} - fg missing entirely

# ❌ FAILS - Lambda scope (bg first, fg last)
get_palette3 = lambda _src, _mode, _variant -> {
    mode = _mode
    variant = _variant
    bg = everforest_src[mode].bg[variant]
    fg = everforest_src[mode].fg
}
everforest_light_hard3 = get_palette3(everforest_src, "light", "hard")
# Result: {mode="light", variant="hard", fg=...} - bg missing entirely

# ❌ STILL FAILS - Even with intermediate variable
get_palette4 = lambda _src, _mode, _variant -> {
    mode = _mode
    variant = _variant
    mode_obj = _src[_mode]
    bg = mode_obj.bg[_variant]
    fg = mode_obj.fg
}
everforest_light_hard4 = get_palette4(everforest_src, "light", "hard")
# Result: Still only the last field appears (fg or bg depending on order, here bg missing)

Expected Behavior

All fields in the returned config should be present regardless of their declaration order. Both fg and bg should appear in all lambda examples.

Actual Behavior

Only the field that appears last in the lambda body appears in the output. The field(s) before it are completely missing.

Environment

• KCL version: 0.12.3-linux-amd64 (installed via go install)
• OS: Debian 13

Analysis Context

The issue was investigated by examining the KCL repository structure. Starting from compiler base(apprently empty), the investigation focused on the evaluator crate, particularly the interaction between scope handling (scope.rs), lazy evaluation (lazy.rs), and execution context (context.rs).

Speculative Analysis

Disclaimer: The following analysis was AI-generated and may be incorrect.(i don't fully understand this). It's provided as a starting point for maintainers who know the codebase.

The issue appears to stem from how KCL handles variables in lambda scopes versus global scope. In global scope, variables are properly evaluated through the lazy evaluation system. In lambda scope, variables seem to be tracked in two parallel systems that don't synchronize correctly.

When a lambda executes:

1. Local variables (_mode, _variant) are stored in the current Scope via add_variable()
2. Fields (fg, bg) have setters recorded in LazyEvalScope via emit_setters()
3. When accessing variables during computation, lambda uses direct scope lookup (get_variable()) which bypasses lazy evaluation(calls undefined value instead of actually triggering evaluation)
4. When constructing the final result, it uses get_value_from_lazy_scope() which only fully evaluates the last accessed field due to backtracking logic

This creates a race condition where earlier fields never get properly forced through the lazy evaluation system, causing them to be missing from the output.

The key files that may contain the issue:

• scope.rs: Variable resolution and lambda scope handling
• lazy.rs: Lazy evaluation and backtracking mechanism
• context.rs: Lambda context management

Possible Impact

This affects any KCL code that uses lambdas to generate config objects with multiple computed fields - a common pattern for configuration generation, theming, and reusable logic.

[kunalworldwide]

The reproduction is clear and the per-field bisect (swapping fg/bg order consistently shows only the last field) strongly points to a scope-resolution bug in lambda body compilation rather than a data-dependency cycle. The analysis in the issue correctly isolates scope.rs, lazy.rs, and context.rs as the likely culprits — particularly the interaction between emit_setters (which records field setters in LazyEvalScope) and get_variable (which may use a direct scope lookup path that bypasses lazy forcing for earlier fields). Can you share the minimal reproducer as a standalone .k file rather than the theming snippet, so the bug can be isolated in the KCL test harness without the Palette schema overhead? A unit test that asserts len(result.fields) == len(lambda.body.fields) for a two-field lambda would pin the regression and prevent re-introduction.

[ahkinsat]

Update: False alarm - this was a syntax misunderstanding, not a bug

After re-reading the docs and testing more carefully, I found the root cause.

I was using:

func1 = lambda x, y -> any {
    a = x
    b = y
}

But KCL treats { ... } as a function body block (like Scala/Rust), not as an implicit return. The last expression is what gets returned - so func1 returns b only.

What I intended and understood (influenced by JavaScript where () => {a: x, b: y} is common) was:

func2 = lambda x, y -> any {
	{
	    a = x
	    b = y
	}
}

I mistakenly thought the -> Type (Palette in my case) part was syntax for a typed dict literal, not the function's return type annotation.

The nested braces { { ... } } create a single expression returning the config object. With this fix applied to my original theming code, both fields appear correctly. No order-dependence, no bug.

Apologies for the noise! And yes, confirmation bias is real - I framed it so convincingly even the LLM I worked with fell for it. 😅

Closing as not a bug. Thanks for your patience!

[kunalworldwide]

Ah, good catch — lambda blocks returning the last expression rather than all assignments makes sense. Thanks for closing the loop on this.