| 20 Mar 2026 |
 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 |
| piegames | But also, having to write a custom GC isn't too bad if one has sufficient freedom in the design constraints | 12:08:27 |
| piegames | Things like "we only have 4 types which need GC", "doesn't have to be super fast", "Values are opaque pointers anyways because of pointer tagging" do make it less horrible | 12:10:21 |
| emily | those aren't the hard parts | 12:10:35 |
| emily | it's stack rooting, esp if you want a sound + precise Rust API (cf. https://manishearth.github.io/blog/2021/04/05/a-tour-of-safe-tracing-gc-designs-in-rust/) | 12:11:27 |
| emily | (let alone ergonomic 😅) | 12:11:34 |
| emily | though refcounting with cycle collection is relatively simpler (but not sure if the perf would be appealing compared to Boehm for a language like Nix that has tons of cycles...) | 12:12:33 |
| piegames | horrors say refcounting will be too slow | 12:13:00 |
