| 20 Mar 2026 |
 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 |
| Coca | borrowed and owned Values are parsed into DOMs, tape doesn't seem to end parsing early but instead goes over the (already partially parsed) mutable input and ends when it finds one. All Values are consistent with returning the first value. | 11:45:44 |
