How are cycles solved in Lobster?

[hubertpnj]

According to the website: "Reference Counting with cycle detection at exit". Does that mean at program exit? I don't believe so, as it would mean that doubly-linked list were unusable without eating memory till the end of the program.

[aardappel]

Yes, at program exit. What that means is that if you want to be using doubly linked lists, you must manually set to nil at least one of the links before you set the head of the list to nil, to avoid garbage. Not doing so is considered a programmer bug.

The cycle detection is just there to inform you you have such a bug, it is not a replacement for a garbage collector.

[hubertpnj]

Won't weak references do the trick? I mean to me this whole idea of compile-time memory management and it's close to Pythonic simplicity, gets almost ruined when I need to break a cycles by hand and it will introduce a lot of boilerplate code

[aardappel]

Let's just say that for all that I've used it for (games and compilers) it has not been an issue.. of ~100 or small to medium size programs I have written in it, maybe 3 have code like this:

for(entities) e:
    e.enemy = nil

Since the enemy field created a cycle. I have so far had no need for doubly linked lists, etc. :)

Weak references come with overhead, either the weak reference itself needs to have some kind of double indirection, a liveness check, or a way to reach other references (akin shared_ptr).. I'd rather not have such overhead, even if some of it can be mitigated by more complexity in the compile time memory management.

The other problem with weak references is they assume nil must be a valid value, which most types in Lobster are trying to get away from.

Lobster also tries to get as much of the "compile time memory management" benefit automatically, i.e. without annotations, which might go against an implementation of weak references whose inefficiency is limited to where it is really needed.

I'd not be against adding a form of weak references that don't have these downsides, but I haven't figured out how to yet :)

[maddanio]

Interesting. Raw pointers are the one thing that i will have a hard time letting go of should i ever leave c++ for rust. Its so often that i build hierarchical structures with cross pointers, and i keep wondering how i could solve it in rust. One of these days i will have to find out:)