5 ms·

The homepage says that Kitten has (will have?) memory management with no garbage collection, and yet the introduction shows that each item on the stack can repr

by creata 6y ago

The homepage says that Kitten has (will have?) memory management with no garbage collection, and yet the introduction shows that each item on the stack can represent arbitrarily large lists, trees, etc. How might this be implemented?

rowanG077 6y ago
See the faq: http://kittenlang.org/faq/ http://kittenlang.org/faq/
- remexre 6y ago
  So I'd imagine it has "linear-like" ownership?
- tom_mellior 6y ago
  The FAQ says: > In addition, stack-based resource management has predictable runtime performance behavior: when you drop a value from the stack, it gets deallocated, no garbage collector required. This cannot possibly work for this language. Stack-based memory management only works as long as all references go from "newer" values (higher on the stack) to "older" ones (deeper on the stack). But this language allows you to write a function that rearranges the stack, for example by swapping the two topmost elements. Consider a scenario where some value x is on top of the stack: x Now we build some sort of heap value that has a reference to x and push it onto the stack: box(x) x Now swap these: x box(x) Then drop x from the stack, for example by printing it. This deallocates x. The stack is now: box(x) But this value is undefined, since x has been deallocated. You have a use-after-free error. I wish people stopped approaching language design from the point of view that the people who have been working on garbage collection for the last 60 years are all idiots who don't see how simple it all is.
  - nerdponx 6y ago
    So the runtime will just randomly segfault or cause memory corruption? That wouldn't make a very useful language, maybe they have a workaround.
    - tom_mellior 6y ago
      Like all other languages voted to the HN front page that claim that they have magically solved memory management, this project's website is simply lying. Looking at https://github.com/evincarofautumn/kitten/issues/193 https://github.com/evincarofautumn/kitten/issues/193: "Does kitten require garbage collection?" -- "Nope. [...] The plan is that boxed lists ([…], List<T>) and closures ({…}) are reference-counted" and https://github.com/evincarofautumn/kitten/issues/131 https://github.com/evincarofautumn/kitten/issues/131: "Explore GC strategies" -- "The C backend currently uses naïve reference counting." A quick skim of kitten.c confirms that objects have a reference count field and are only really released when it drops to zero. (I didn't find code that increments the reference count, but I find it hard to care.) The project's website claims: > Automatic management of memory and resources with no garbage collector. One can weakly argue that many people mean tracing garbage collection when they speak of garbage collection, and that reference counting is not garbage collection in this narrow sense. This is unhelpful at best. The FAQ has the claim I quoted above, of which the "when you drop a value from the stack, it gets deallocated" appears to be simply false. I should add that I'm aware that this project is incomplete, but that doesn't excuse making wildly implausible claims.

by creata 6y ago

rowanG077 6y ago

See the faq: http://kittenlang.org/faq/ http://kittenlang.org/faq/

remexre 6y ago
So I'd imagine it has "linear-like" ownership?
tom_mellior 6y ago
The FAQ says: > In addition, stack-based resource management has predictable runtime performance behavior: when you drop a value from the stack, it gets deallocated, no garbage collector required. This cannot possibly work for this language. Stack-based memory management only works as long as all references go from "newer" values (higher on the stack) to "older" ones (deeper on the stack). But this language allows you to write a function that rearranges the stack, for example by swapping the two topmost elements. Consider a scenario where some value x is on top of the stack: x Now we build some sort of heap value that has a reference to x and push it onto the stack: box(x) x Now swap these: x box(x) Then drop x from the stack, for example by printing it. This deallocates x. The stack is now: box(x) But this value is undefined, since x has been deallocated. You have a use-after-free error. I wish people stopped approaching language design from the point of view that the people who have been working on garbage collection for the last 60 years are all idiots who don't see how simple it all is.
- nerdponx 6y ago
  So the runtime will just randomly segfault or cause memory corruption? That wouldn't make a very useful language, maybe they have a workaround.
  - tom_mellior 6y ago
    Like all other languages voted to the HN front page that claim that they have magically solved memory management, this project's website is simply lying. Looking at https://github.com/evincarofautumn/kitten/issues/193 https://github.com/evincarofautumn/kitten/issues/193: "Does kitten require garbage collection?" -- "Nope. [...] The plan is that boxed lists ([…], List<T>) and closures ({…}) are reference-counted" and https://github.com/evincarofautumn/kitten/issues/131 https://github.com/evincarofautumn/kitten/issues/131: "Explore GC strategies" -- "The C backend currently uses naïve reference counting." A quick skim of kitten.c confirms that objects have a reference count field and are only really released when it drops to zero. (I didn't find code that increments the reference count, but I find it hard to care.) The project's website claims: > Automatic management of memory and resources with no garbage collector. One can weakly argue that many people mean tracing garbage collection when they speak of garbage collection, and that reference counting is not garbage collection in this narrow sense. This is unhelpful at best. The FAQ has the claim I quoted above, of which the "when you drop a value from the stack, it gets deallocated" appears to be simply false. I should add that I'm aware that this project is incomplete, but that doesn't excuse making wildly implausible claims.