Hacker News Reader

Comment by levodelellis | Hacker News Reader

Whenever my compiler comes up the first question tends to be why? I found that everyones "why" are specific. Some people want to know how many libraries exist, others want to know specifically how many high level (or low level) libraries there are for easy of use (or performance). Some want to know what's unique others want to know the goals. It's hard to know what people want so I'll do my best on answering questions

View on HN

How do you achieve automatic memory management without GC (including ARC)?

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)

So does that forbid mutually recursive functions, threading, and self referential data structures?

Yes self referential data structures are forbidden. No threading at the moment.

Does this lang have an explicit effects system? Does the memory management work similar to PerceusRC in Koka, or is it more similar to ASAP?

I'm not familiar with those

Could you go into more detail? I am quit interested and would love to learn more.

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.

Yes, I would like to emphasize the last point.

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

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?

> if you implicitly claim to have solved some huge, difficult research problem but provide no real details

You do realize you can download the compiler and confirm for yourself that it's all working right this very moment?

There's probably a few aliasing bugs since I add new features. types and haven't tried to break my code or find difficult to run into bugs

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.

Reply on news.ycombinator.com