| 20 Mar 2026 |
 aloisw | This was specifically rejected in favour of warning the user that it's just not supported any more. | 18:03:38 |
 emily | I'm not sure a string literal syntax that can't be used to form all of the valid strings in the language is a move in a less busted direction… | 18:08:36 |
| emily | (or what the problem with ''\<space> is, if ''\' is okay) | 18:09:16 |
 piegames | In reply to @emilazy:matrix.org
(or what the problem with ''\<space> is, if ''\' is okay) The latter was unfortunately necessary for escaping a ' at the end of a ''-string, because ''' is already defined to mean '' | 18:43:17 |
| emily | I think it's necessary before the end in some cases too. (but ''\<space> is also necessary as well, clearly) | 18:44:13 |
| piegames | It's not strictly necessary, because ${""} exists and is, arguably, no more hacky | 20:03:45 |
| aloisw | With that you could do single quote at the end, too. | 20:55:10 |
| piegames | heh | 21:12:14 |
| piegames | I totally did not think of that | 21:12:20 |
| 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 |
