I'm not sure what details you want. The easy one to explain is itoa. Since 64bit ints can be at most 20 digits the function returns a fixed length array. Currently it's u8[21] because I've wanted an extra byte for null (for testing before I had print implemented). I'm not sure if I'll keep the extra byte, anyway since 21 bytes fits on the stack the caller function will allocate it on the stack so it doesn't need to copy it. But it doesn't have to be on the stack, if you write `obj.data = itoa(anInt)` the compiler will pass `obj.data` in. If it's a local variable then the compiler would have to decide if it should be on the stack or heap. Passing in a buffer gets rid of useless copies for the case where optimizers can't inline the function.
I guess the broader question is how do you achieve automatic memory management without something like Automatic Reference Counting (like swift), the ownership/lifetime systems from rust, or the generic effect system of Pony?
Ergonomically solving this problem is a major research area, so if you’ve found a solution to it’d be worth presenting that front and center.
Are you saying I should write a paper? I'm not sure how much it would help when a lot of it is intricate to the design of the language. I have no idea what the page limit of papers are and what the point would be besides for fun. I never had fun writing a paper either
Not GP but it is why I asked this question and the follow up. There are a lot of PL folks who are exploring this particular design problem (static analysis in the compiler to take care of the hard problems of memory management).
What would be very compelling are some code examples and either high level descriptions of what the compiler is doing or some analysis of the type system and IRs the compiler uses to verify correctness.
Particularly things like ownership and lifetimes. These can be pretty nuanced in degenerate cases and it would be interesting to see how you solved them.
Like take Rust. It has ARC to be sure, but the core semantics behind its "compile time GC" are pretty well defined and easy to follow so people have faith that they work (they're also provably correct). If you have some motivating examples and descriptions of how the language solves them it would be very compelling to see!
Essentially this isn't an attack on the project, it's just curiosity about the approach and implementation. It's easy to poke at code examples and see that you're right, what is more valuable to folks that are approaching the same problems is how you got there.
I'm mostly suggesting that if you implicitly claim to have solved some huge, difficult research problem but provide no real details about how, people are going to be skeptical. This doesn't have to mean a formal research paper. Even one page on your website describing your approach (potentially with comparisons to other state-of-the-art languages like Swift, Rust, and Koka) would be helpful for potential users trying to understand your language's capabilities.
Just as some basic questions you might want to answer:
1. If I allocate some memory and store a reference to it in a struct or object, how do you track ownership for that memory? Can I alias it? Store references to it in multiple structs? How do you know that it's safe to free that memory without reference counting?
2. Am I allowed to allocate memory in a function and return a reference to that memory? How do you ensure that memory lives long enough for those references to be valid?
3. Are multiple aliases allowed to overlap with each other? If so, how do you prevent (e.g.,) type confusion from one mutiple alias changing the data out from under the other?
