| 20 Mar 2026 |
 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 |
| 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) mutated input and ends when it finds one. All Values are consistent with returning the first value. | 11:47:25 |
| emily | (btw, what is the plan for the GC story if eval is moving into Rust?) | 11:50:22 |
| piegames | Will have to be rewritten eventually. Library search is still ongoing, but a custom solution might be necessary | 11:57:15 |
| emily | I meant more non-eventually, since interop with Boehm could be weird (but maybe viable if done carefully) | 12:00:08 |
| emily | custom GC in Rust is definitely not for the faint of heart, very tricky thing to write soundly (in any language but the Rust API side of things especially... admittedly Boehm punts on both the soundness and much of the complexity with conservative scanning) | 12:01:47 |
| piegames | Well, for now I want to see if it is viable to have Rust code use C++ values via cxx and opaque pointers without too much pain | 12:07:30 |
