ltungv

5 ms·

1. 1.▲
   by ltungv 2y ago

   Thanks for sharing. I've enjoyed every single piece of your writing so far. This will be in the arsenal of materials I'll use when I again get confused about variance.
2. 2.▲
   by ltungv 2y ago

   Thanks for sharing! That's a much more interesting project compared to mine xD. I had the intuition that rust-gc could be implemented in a simpler fashion by not being generic. Glad to see someone actually had it done.
3. 3.▲
   by ltungv 2y ago

   Thanks for writing the book! I've had an amazing experience tinkering with it over the years. I see that the license now includes images. I was unsure of how to have proper attribution and had just a link to a particular section of the
4. 4.▲
   by ltungv 2y ago

   Ah! I could imagine a table backed by an array of Cell since all the possible values in that table implement Copy. There is probably a better way for the table to have interior immutability. But I think I get what you were saying.
5. 5.▲
   by ltungv 2y ago

   Yes, the borrows were only held for roughly a single instruction. But I don't see how you can mutate the Table/HashMap of fields in an object with only Cell tho
6. 6.▲
   by ltungv 2y ago

   Thanks a lot for the insight. I think if I do it the way shifgrethor did, I can have GC at arbitrary time. But I'm not so sure about that. With the way Rust may perform optimizations on the assumption of no alias, I guess there's
7. 7.▲
   by ltungv 2y ago

   Can you elaborate on why it's too strict? I got RefCell working and passed to test suite just fine. Maybe the suite don't take into account some that's specific to Rust. If I remember correctly, there were some panics cause b
8. 8.▲
   by ltungv 2y ago

   haha, glad to know that I'm not the only one
9. 9.▲
   by ltungv 2y ago

   Nice, thanks for sharing. Definitely gonna look into how you do it, I couldn't get as close to clox like you did
10. 10.▲
    by ltungv 2y ago

    Thanks for the suggestion. I updated it with more explicit citations. After seeing your comment, I just looked around and saw that no license was given for the images. I should probably draw my own.
11. 11.▲
    by ltungv 2y ago

    If someone else depends on this project, I'd definitely not implement the questionable stuff. You're right that proving whether it's safe can be lots of fun, and I'm planning to try it out. Based on what I've read,
12. 12.▲
    by ltungv 2y ago

    Oh right. I read about this once or twice and have never looked at it again. I've made the (wrong) assumption that this function needs some compile-time help. Is it all done at runtime? Or does that depend on the actual C implementatio
13. 13.▲
    by ltungv 2y ago

    I implemented exactly what you were saying here ( https://github.com/ltungv/rox/commit/6a611e7acb3b36d0a3a4376... ). But where's the fun in that?
14. 14.▲
    by ltungv 2y ago

    I'd read your article, and it was lovely. It nudged me to just go unsafe and implement some of the data structures from scratch.
15. 15.▲
    by ltungv 2y ago

    I'm aware of all the issues mentioned. But for this particular project, I simply don't care as long as it passes Lox's test suite xD. I went this path just to see how easy it is to get tripped by unsafe while knowing that the
16. 16.▲
    by ltungv 2y ago

    The borrow-checker helps when you're writing Rust code. But when writing an interpreter for another language, you kinda have to support its semantics. In Lox, there's no move semantic, no borrowing, almost everything is a heap-all
17. 17.▲
    by ltungv 2y ago

    Yeah, it's a self-enforced contract that objects of type Gc<T> are only ever touched by the virtual machine, but I get your point.
18. 18.▲
    by ltungv 2y ago

    Yeah true, this breaks all sorts of contracts that we have with Rust xD. But if mark-and-sweep is implemented correctly, then no reference is ever held across the GC. Though, there's gonna be lots of pain debugging when you got it wron