| 20 Mar 2026 |
 piegames | hmm | 21:12:24 |
 toonn | Is a literal still a literal if it requires interpolation though? | 22:20:31 |
| piegames | That's a philosophical question | 22:56:07 |
| piegames | Bonus points for: semantically, strings with interpolations are parsed as a concatenation right now, but so are escapes. Yes this is bogus | 22:57:06 |
| piegames | Bonus bonus points: this is load-bearing and semantically observable in Flakes where literals are allowed but no concatenations, and changing the parser thus changes the language of flake files | 22:57:53 |
 zoë (she/her) | sorry to interrupt the debate, but is the fact that break doesn't force its argument (unlike e.g. trace and warn) really intended? it causes break calls to be opaque in some situations (e.g. isAttrs {} != isAttrs (break {}), and mapAttrs f (break {}) always errors out, complaining about about the argument being a thunk and not a set), which means that it can potentially break (ha) a lot of code that relies on those | 23:07:45 |
| zoë (she/her) | i know the test suite is not exactly the best thing to go by, but adding forceValue(args[0]) to prim_break "only" breaks two tests, in the repl. from what i can tell, it seems to change where the error's 0th frame is located for some reason | 23:11:42 |
| zoë (she/her) | * i know the test suite is not exactly the best thing to go by, but adding forceValue(args[0]) to prim_break "only" breaks two tests, in the repl. from what i can tell, it seems to change where the breakpoint/error's 0th frame is located for some reason | 23:11:48 |
| zoë (she/her) | * sorry to interrupt the debate, but is the fact that break doesn't force its argument (unlike e.g. trace and warn) really intended? it causes break calls to be opaque in some situations (e.g. isAttrs {} != isAttrs (break {}), and mapAttrs f (break {}) always errors out, complaining about about the argument being a thunk and not a set), which means that it can potentially break (ha) a lot of code that relies on those
(and from experience it has bitten me every time i use break, to the point that i carry the declaration brk = x: builtins.seq (break x) x in every file i debug) | 23:13:10 |
| zoë (she/her) | * sorry to interrupt the debate, but is the fact that break doesn't force its argument (unlike e.g. trace and warn) really intended? it causes break calls to be opaque in some situations (e.g. isAttrs {} != isAttrs (break {}), and mapAttrs f (break {}) always errors out, complaining about about the argument being a thunk and not a set), which means that it can potentially break (ha) a lot of code that relies on those. does that mean it'd be considered a breaking change to do that (is break even considered part of the language's stability contract?)
(and from experience it has bitten me every time i use break, to the point that i carry the declaration brk = x: builtins.seq (break x) x in every file i debug) | 23:14:15 |
| zoë (she/her) | nvm, the only differences are actually just in the final stack that's shown -- in the current tests, there's a smaller backtrace (which isn't very informative imo), but with the patch it traces the whole call-stack from the root expression instead | 23:21:20 |
| zoë (she/her) | * nvm, in both failing tests, the only differences are actually just in the call stack that's displayed -- in the current tests, there's a smaller backtrace (which isn't very informative imo), but with the patch it traces the whole call-stack from the root expression instead | 23:24:23 |
| zoë (she/her) | * nvm, in both failing tests, the only differences are actually just in the call stack (either from :bt or after quitting) -- in the current tests, there's a smaller backtrace (which isn't very informative imo), but with the patch it traces the whole call-stack from the root expression instead | 23:24:46 |
| piegames | TIL about break | 23:25:48 |
| piegames | And oid | 23:25:51 |
| piegames | * And oof | 23:26:04 |
| piegames | This is such a layering violation | 23:26:14 |
| piegames | https://git.lix.systems/lix-project/lix/src/branch/main/lix/libexpr/primops.cc#L647 but the implementation does not look super shady to me (well, besides the normal amount of cursedness) | 23:28:23 |
| zoë (she/her) | yeah no i was surprised at how little code was actually there | 23:28:50 |
| zoë (she/her) | * yeah no i was surprised at how little code was actually there too | 23:28:55 |
| piegames | It just passes the value it gets through like a wrapper, which makes intuitive sense to me | 23:28:56 |
| piegames | In reply to @blokyk:matrix.org
sorry to interrupt the debate, but is the fact that break doesn't force its argument (unlike e.g. trace and warn) really intended? it causes break calls to be opaque in some situations (e.g. isAttrs {} != isAttrs (break {}), and mapAttrs f (break {}) always errors out, complaining about about the argument being a thunk and not a set), which means that it can potentially break (ha) a lot of code that relies on those. does that mean it'd be considered a breaking change to do that (is break even considered part of the language's stability contract?)
(and from experience it has bitten me every time i use break, to the point that i carry the declaration brk = x: builtins.seq (break x) x in every file i debug) Can you paste the errors maybe? | 23:29:49 |
| zoë (she/her) | me too, but i don't know how the evaluator actually works internally, and i saw that trace has a forceValue(args[1]), and i know for a fact that trace doesn't have that bug, so i figured it'd fix it | 23:29:57 |
| zoë (she/her) | sure hold on | 23:30:01 |
| piegames | I have a hunch this might be a callsite problem | 23:30:14 |
| piegames | In reply to @blokyk:matrix.org
me too, but i don't know how the evaluator actually works internally, and i saw that trace has a forceValue(args[1]), and i know for a fact that trace doesn't have that bug, so i figured it'd fix it I mean you can just try it out and see if it helps | 23:30:42 |
| zoë (she/her) | nix-repl> builtins.mapAttrs (n: v: v) (break { a = 5; })
error:
… while calling the 'mapAttrs' builtin
at «string»:1:1:
1| builtins.mapAttrs (n: v: v) (break { a = 5; })
| ^
… while evaluating the second argument passed to builtins.mapAttrs
error: expected a set but found a thunk: «thunk»
| 23:31:43 |
| zoë (she/her) | yep that's what i did and it seems to work how i'd expect (i.e. the above expression evaluates fine) | 23:32:40 |
| piegames | And if you replace break with identity or with trace it works? | 23:32:56 |
| zoë (she/her) | it seems to be the case with most of the builtins i've tried, from memory | 23:33:13 |
