| 20 Mar 2026 |
 emily | see also toml11 bumps sleepwalking into breaking Nixpkgs lib tests etc. | 11:23:20 |
| emily | any complete of builtin parser implementation like that should most likely come with a period of running both of them and aborting on any divergence | 11:24:03 |
| emily | (how many hours do you have to learn about XML interoperability issues?) | 11:25:26 |
| emily | (it's a miracle Nix at least only has it as an output format) | 11:25:40 |
| emily | (and I like XML!) | 11:25:46 |
| emily | I really don't think so. the JSON iceberg is not the Nix iceberg | 11:27:26 |
| emily | a warning about input you don't control is not actionable or going to go anywhere, unless it's a truly unfixable interoperability problem | 11:28:29 |
| emily | it's unlikely JSON documents people produce solely for consumption in Nix will have duplicate keys because most language APIs won't do that | 11:29:07 |
| emily | Lix accepting escaped NUL codepoints in JSON that correctly-written Nixpkgs library functions violate their contract on is far more likely to cause interoperability issues than duplicate keys tbh | 11:30:11 |
| emily | (and that's a case where there actually is current and historical divergence, so a warning would be much more justifiable there...) | 11:30:58 |
| emily | interesting to see simd-json diverge, though it also has several correctness issues open on GitHub, some from years ago 😅 | 11:34:00 |
| emily | wonder if they somehow get better perf from that result or something | 11:34:38 |
| emily | are you sure it's not storing both values in a parse tree type form and the lookup is just terminating on the first one actually? | 11:35:18 |
 Coca | My hunch was that simd-json can get the earliest acceptable value and then stop parsing, at least with the tape Value, but I would have to see | 11:35:49 |
| emily | oh I guess it's the same serde type(?) | 11:36:05 |
| emily | ah I see | 11:36:08 |
| Coca | its not the same serde type to be clear tho | 11:36:30 |
| emily | yeah if it's looking up from a string rather than parsing into a full DOM that makes sense | 11:36:31 |
| emily | also means it'll happily eat up a ton of invalid documents... | 11:36:43 |
 piegames | Unfortunately, this is not possible because of impurities, I was told | 11:36:57 |
| piegames | I already had the idea of having the whole bytecode interpreter run in sync with the old interpreter for verification purposes, and unfortunately that's not possible | 11:37:26 |
| emily | I'm not sure what you mean | 11:37:31 |
| emily | well for full interpretation sure | 11:37:42 |
| emily | not for JSON parsing | 11:38:18 |
| emily | no existing thunks can go into fromJSON results | 11:38:51 |
| piegames | ah, you meant only in the JSON builtins, not all builtins | 11:39:18 |
| emily | for serialization it's a bit more involved but not unfixably especially considering you'll hit the same thunks | 11:39:30 |
| piegames | might be feasible then, yes | 11:39:22 |
| emily | well, for another format parser/serializer really (but I guess JSON, TOML, ATerm, and arguably XML are the only really load-bearing ones there) | 11:41:09 |
| emily | * | 11:41:15 |
