6 ms·

Cone is developed as a proof of concept for the author's paper Gradual Memory Management[1]. The author is experienced in language development and has previousl

Cone is developed as a proof of concept for the author's paper Gradual Memory Management[1]. The author is experienced in language development and has previously written Acorn. It was seen as more appropriate to write a new language rather than trying to tack the idea onto an existing language. [1]:http://jondgoodwin.com/pling/gmm.pdf http://jondgoodwin.com/pling/gmm.pdf

duneroadrunner 8y ago
If maximum (or just more) flexibility wrt memory safety is the goal, I might suggest the author take a look at SaferCPlusPlus. In particular, it supports memory safe pointer/references[1][2] that can target objects associated with different allocators (including stack allocated objects) without, as the author desires, imposing the "sometimes confining" restrictions that Rust does. And in terms of data race safety, it allows you to hold "read-lock" and "write-lock" pointer/references simultaneously in the same thread [3], which adds a little extra functionality (and maybe convenience). [1] shameless plug: https://github.com/duneroadrunner/SaferCPlusPlus#registered-pointers https://github.com/duneroadrunner/SaferCPlusPlus#registered-... [2] https://github.com/duneroadrunner/SaferCPlusPlus#norad-pointers https://github.com/duneroadrunner/SaferCPlusPlus#norad-point... [3] https://github.com/duneroadrunner/SaferCPlusPlus#tasyncsharedv2readwriteaccessrequester https://github.com/duneroadrunner/SaferCPlusPlus#tasyncshare...
- anp 8y ago
  It's good that you include "shameless plug" in these posts to clarify, but it would be much much clearer if you included more explicit phrasing along the lines of "I only post to HN to plug my project called SaferCPlusPlus, not ever to talk about the submitted article. You can see here: https://news.ycombinator.com/threads?id=duneroadrunner." https://news.ycombinator.com/threads?id=duneroadrunner."
  - Zanni 8y ago
    You've got some stray punctuation that breaks your link. Fixed link for the lazy: https://news.ycombinator.com/threads?id=duneroadrunner https://news.ycombinator.com/threads?id=duneroadrunner
  - duneroadrunner 8y ago
    > I only post to HN to plug my project called SaferCPlusPlus From this account, yes. Too much? Sorry, (you can see) I haven't gotten much feedback. Or is having a separate, project-specific account in itself not cool? > not ever to talk about the submitted article. I try to post/plug only when I think it's relevant. I think. For example, in the "gmm.pdf" linked in the comment I responded to, the author says that specific types of references can only target objects owned/allocated by the associated allocator. There is no available reference type that can target objects from different allocators. References in Rust, for example, can target any object regardless of how they were allocated, but imposes strict restrictions that the author implies he's trying to avoid. So I tried to point out that SaferCPlusPlus has pointer types that can safely target objects allocated by different allocators and do not have the strict restrictions of Rust's references. As far as I know, these types of pointers are (still) unique to SaferCPlusPlus, and I assume I am one of a few people who is familiar with these pointers. But there's nothing proprietary about them. If the author is constructing a language with a goal of flexibility wrt to memory safety, I thought he might consider whether such pointer/reference types might be compatible with his language design. I think they unquestionably increase flexibility (while maintaining memory safety).
    - jondgoodwin 8y ago
      > There is no available reference type that can target objects from different allocators. Cone actually does support Rust-like, lifetime-constrained borrowed references which can do exactly that safely. Cone also supports raw pointers (however de-reference safety is the responsibility of the programmer). I appreciate the chance to learn about your language's unique form of reference type. I am less likely to call them safe than you, no doubt because I use a different criteria for safety. A key requirement I have placed on references (vs. pointers) is that you can always de-reference them and get a valid value with no chance of exception. I don't think your references would comply with this. A Cone programmer would need to use raw pointers to throw off the shackles of lifetime constraints but, unlike with your references, they could not expect such pointers to turn into nullptr if the object they refer to has been freed. Given the nature of Cone's design, there is no way to accomplish this mechanic with decent performance, especially given that borrowed references and raw pointers are both able to point inside an allocated object. I do appreciate your bringing it to my attention and wish you all the best with getting others to learn about and adopt your language.

duneroadrunner 8y ago

If maximum (or just more) flexibility wrt memory safety is the goal, I might suggest the author take a look at SaferCPlusPlus. In particular, it supports memory safe pointer/references[1][2] that can target objects associated with different allocators (including stack allocated objects) without, as the author desires, imposing the "sometimes confining" restrictions that Rust does. And in terms of data race safety, it allows you to hold "read-lock" and "write-lock" pointer/references simultaneously in the same thread [3], which adds a little extra functionality (and maybe convenience). [1] shameless plug: https://github.com/duneroadrunner/SaferCPlusPlus#registered-pointers https://github.com/duneroadrunner/SaferCPlusPlus#registered-... [2] https://github.com/duneroadrunner/SaferCPlusPlus#norad-pointers https://github.com/duneroadrunner/SaferCPlusPlus#norad-point... [3] https://github.com/duneroadrunner/SaferCPlusPlus#tasyncsharedv2readwriteaccessrequester https://github.com/duneroadrunner/SaferCPlusPlus#tasyncshare...

anp 8y ago
It's good that you include "shameless plug" in these posts to clarify, but it would be much much clearer if you included more explicit phrasing along the lines of "I only post to HN to plug my project called SaferCPlusPlus, not ever to talk about the submitted article. You can see here: https://news.ycombinator.com/threads?id=duneroadrunner." https://news.ycombinator.com/threads?id=duneroadrunner."
- Zanni 8y ago
  You've got some stray punctuation that breaks your link. Fixed link for the lazy: https://news.ycombinator.com/threads?id=duneroadrunner https://news.ycombinator.com/threads?id=duneroadrunner
- duneroadrunner 8y ago
  > I only post to HN to plug my project called SaferCPlusPlus From this account, yes. Too much? Sorry, (you can see) I haven't gotten much feedback. Or is having a separate, project-specific account in itself not cool? > not ever to talk about the submitted article. I try to post/plug only when I think it's relevant. I think. For example, in the "gmm.pdf" linked in the comment I responded to, the author says that specific types of references can only target objects owned/allocated by the associated allocator. There is no available reference type that can target objects from different allocators. References in Rust, for example, can target any object regardless of how they were allocated, but imposes strict restrictions that the author implies he's trying to avoid. So I tried to point out that SaferCPlusPlus has pointer types that can safely target objects allocated by different allocators and do not have the strict restrictions of Rust's references. As far as I know, these types of pointers are (still) unique to SaferCPlusPlus, and I assume I am one of a few people who is familiar with these pointers. But there's nothing proprietary about them. If the author is constructing a language with a goal of flexibility wrt to memory safety, I thought he might consider whether such pointer/reference types might be compatible with his language design. I think they unquestionably increase flexibility (while maintaining memory safety).
  - jondgoodwin 8y ago
    > There is no available reference type that can target objects from different allocators. Cone actually does support Rust-like, lifetime-constrained borrowed references which can do exactly that safely. Cone also supports raw pointers (however de-reference safety is the responsibility of the programmer). I appreciate the chance to learn about your language's unique form of reference type. I am less likely to call them safe than you, no doubt because I use a different criteria for safety. A key requirement I have placed on references (vs. pointers) is that you can always de-reference them and get a valid value with no chance of exception. I don't think your references would comply with this. A Cone programmer would need to use raw pointers to throw off the shackles of lifetime constraints but, unlike with your references, they could not expect such pointers to turn into nullptr if the object they refer to has been freed. Given the nature of Cone's design, there is no way to accomplish this mechanic with decent performance, especially given that borrowed references and raw pointers are both able to point inside an allocated object. I do appreciate your bringing it to my attention and wish you all the best with getting others to learn about and adopt your language.