lix-project/lix

Fork 58

Extra strictness for constants #746

New issue

Open

opened 2025-03-18 11:46:15 +00:00 by raito · 5 comments

raito commented

2025-03-18 11:46:15 +00:00

Owner

CppNix decided to adopt extra strictness for constants, usually, it can create some issues but here, the idea is to have:

({ foo ? bar, bar ? 12 }: [ foo ]) { }

be stricter in the 12 constant, i.e. the result should be [ 12 ] instead of [ <thunked 12>].

Describe the solution you'd like

Adopting this behavior.

Describe alternatives you've considered

Having a behavior difference here which is fine. It's only visible for people working on Nix implementations that tries to measure how lazy they are for correctness, e.g. Snix.

Additional context

cc @roberth @flokli

## Is your feature request related to a problem? Please describe. CppNix decided to adopt extra strictness for constants, usually, it can create some issues but here, the idea is to have: ``` ({ foo ? bar, bar ? 12 }: [ foo ]) { } ``` be stricter in the `12` constant, i.e. the result should be `[ 12 ]` instead of `[ <thunked 12>]`. ## Describe the solution you'd like Adopting this behavior. ## Describe alternatives you've considered Having a behavior difference here which is fine. It's only visible for people working on Nix implementations that tries to measure how lazy they are for correctness, e.g. Snix. ## Additional context cc @roberth @flokli

pennae commented

2025-03-18 11:51:47 +00:00

Owner

does this provide a performance advantage? otherwise nack. the evaluator is a garbage fire and changing user-invisible semantics to make test suites of other projects simpler is foolish at best.

raito changed title from ~~Extra laziness for constants~~ to Extra strictness for constants

2025-03-18 12:30:23 +00:00

flokli commented

2025-03-18 12:33:26 +00:00

It's not to accomodate the Snix test suite, see the commit message in https://cl.snix.dev/c/snix/+/30090. We updated our test (which tests something else) to not run into this corner case.

does this provide a performance advantage? otherwise nack.

Robert mentioned that's probably the reason. Also see https://github.com/NixOS/nix/issues/12666.

It's not to accomodate the Snix test suite, see the commit message in https://cl.snix.dev/c/snix/+/30090. We updated our test (which tests something else) to not run into this corner case. > does this provide a performance advantage? otherwise nack. Robert mentioned that's probably the reason. Also see https://github.com/NixOS/nix/issues/12666.

jade added the

Area/evaluator

Area/language

labels

2025-03-18 19:47:22 +00:00

raito added the

release-blocker

label

2025-11-18 02:40:42 +00:00

raito commented

2025-11-18 02:40:55 +00:00

Author

Owner

This is marked as a release blocker to figure out or not if this has practical performance implications in the ecosystem.

raito self-assigned this

2025-11-18 02:40:58 +00:00

pennae added this to the 2.95 milestone

2025-12-01 14:51:31 +00:00

raito commented

2025-12-07 00:24:02 +00:00

Author

Owner

@piegames would be a great test exercise for Flaker to run this over the ecosystem with this change and without to perform performance significance testing, it's not particularly urgent but can I tentatively delegate to you this item for 2.95.0?

piegames commented

2025-12-07 17:07:52 +00:00

Member

Flaker still can't do any evaluation testing as of today, and getting it to that point is not ins scope for 2.95 where we'll focus on the current syntax deprecations.

Unless the strictness change has a significant performance impact or is really simple to implement, I'd like to put off such optimizations until we have a bytecode evaluator, where adding a constant propagation pass should be comparatively trivial

Flaker still can't do any evaluation testing as of today, and getting it to that point is not ins scope for 2.95 where we'll focus on the current syntax deprecations. Unless the strictness change has a significant performance impact or is really simple to implement, I'd like to put off such optimizations until we have a bytecode evaluator, where adding a constant propagation pass should be comparatively trivial