4 ms·
Would you accept a short answer? The 'short' answer is the compiler tracks various things such as memory owner (for alloc) and lifetime (for constructors/destru
by levodelellis 4y ago
Would you accept a short answer? The 'short' answer is the compiler tracks various things such as memory owner (for alloc) and lifetime (for constructors/destructors). The compiler enforces rules so it's clear (to the compiler) if the memory owner belongs to the caller function (for example ReadEntireFile), the parent function (itoa causes the calling function to pass in a hidden buffer for it to use) and if it's on the stack, heap or belongs to an object (class struct or array)
- duped 4y agoSo does that forbid mutually recursive functions, threading, and self referential data structures?
- levodelellis 4y agoYes self referential data structures are forbidden. No threading at the moment.
- alexisread 4y agoDoes this lang have an explicit effects system? Does the memory management work similar to PerceusRC in Koka, or is it more similar to ASAP?
- levodelellis 4y agoI'm not familiar with those
- exysle 4y agoCould you go into more detail? I am quit interested and would love to learn more.
- levodelellis 4y agoI'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.
- necubi 4y agoI 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.
- exysle 4y agoYes, I would like to emphasize the last point.
- levodelellis 4y agoAre 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
- necubi 4y agoI'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?