3 ms·

No tail recursion at the moment but it's something I'd be interested in adding later. I'm being very conservative with adding different type constructs but sur

No tail recursion at the moment but it's something I'd be interested in adding later. I'm being very conservative with adding different type constructs but sure, Rust & Go certainly gets a lot of things right in that department and I'll consider their solutions for the future development of Carp.

nickpsecurity 10y ago
Neat to see a contender to replace what should've had plenty of adoption in this area: https://en.wikipedia.org/wiki/PreScheme https://en.wikipedia.org/wiki/PreScheme I still don't see a clear answer to junkie's question despite a huge thread. Let's be specific: "Where no GC is used, how exactly do you handle the issue of memory safety? Is it no safety like C, a specific analysis like Rust, or something different entirely?" Far as concurrency, you probably know about Rust's scheme. The ones that came before it that you might want to consider were Ada Ravenscar and Eiffel's SCOOP. https://en.wikipedia.org/wiki/Ravenscar_profile https://en.wikipedia.org/wiki/Ravenscar_profile http://www.sigada.org/ada_letters/jun2004/ravenscar_article.pdf http://www.sigada.org/ada_letters/jun2004/ravenscar_article.... https://en.wikipedia.org/wiki/SCOOP_(software) https://en.wikipedia.org/wiki/SCOOP_(software) http://cme.ethz.ch/publications/ http://cme.ethz.ch/publications/ SCOOP might be the more interesting of the two for you. It was deployed in real-world apps in Eiffel first. Then, a team ported it to Java. It had a performance penalty. One of the many works in publications... don't remember which... did something ("slices?") that knocked out almost all that overhead. Another model-checked it to eliminate a few errors in SCOOP model. I see one on message-passing. So much badass work and results on SCOOP model I've been annoyed that it was ignored by mainstream for so long. So, hope those help in your thinking on tackling concurrency. Personally glad I looked it up for you as I found this very, interesting project for safe use of GPU's: http://se.inf.ethz.ch/people/poskitt/publications/Kolesnichenko-PNM.GPCE.2015.pdf http://se.inf.ethz.ch/people/poskitt/publications/Kolesniche...
- eriksvedang 10y ago
  Thanks for the links! The short answer is that safety is handled similar to Rust, using lifetime analysis. It's quite a bit more simplistic than Rust at the moment though. Also, some checks are done at runtime (like bounds checking on arrays, when turned on).
  - rurban 10y ago
    Using the information on dependent types and some inference and eliminate run-time type checks in those cases would be a nice type-checker job, e.g. for the sicp/solver.
  - nickpsecurity 10y ago
    Ok. There we go. It's actually what I had in mind for PreScheme. You just gave me more confidence in it.

nickpsecurity 10y ago

Neat to see a contender to replace what should've had plenty of adoption in this area: https://en.wikipedia.org/wiki/PreScheme https://en.wikipedia.org/wiki/PreScheme I still don't see a clear answer to junkie's question despite a huge thread. Let's be specific: "Where no GC is used, how exactly do you handle the issue of memory safety? Is it no safety like C, a specific analysis like Rust, or something different entirely?" Far as concurrency, you probably know about Rust's scheme. The ones that came before it that you might want to consider were Ada Ravenscar and Eiffel's SCOOP. https://en.wikipedia.org/wiki/Ravenscar_profile https://en.wikipedia.org/wiki/Ravenscar_profile http://www.sigada.org/ada_letters/jun2004/ravenscar_article.pdf http://www.sigada.org/ada_letters/jun2004/ravenscar_article.... https://en.wikipedia.org/wiki/SCOOP_(software) https://en.wikipedia.org/wiki/SCOOP_(software) http://cme.ethz.ch/publications/ http://cme.ethz.ch/publications/ SCOOP might be the more interesting of the two for you. It was deployed in real-world apps in Eiffel first. Then, a team ported it to Java. It had a performance penalty. One of the many works in publications... don't remember which... did something ("slices?") that knocked out almost all that overhead. Another model-checked it to eliminate a few errors in SCOOP model. I see one on message-passing. So much badass work and results on SCOOP model I've been annoyed that it was ignored by mainstream for so long. So, hope those help in your thinking on tackling concurrency. Personally glad I looked it up for you as I found this very, interesting project for safe use of GPU's: http://se.inf.ethz.ch/people/poskitt/publications/Kolesnichenko-PNM.GPCE.2015.pdf http://se.inf.ethz.ch/people/poskitt/publications/Kolesniche...

eriksvedang 10y ago
Thanks for the links! The short answer is that safety is handled similar to Rust, using lifetime analysis. It's quite a bit more simplistic than Rust at the moment though. Also, some checks are done at runtime (like bounds checking on arrays, when turned on).
- rurban 10y ago
  Using the information on dependent types and some inference and eliminate run-time type checks in those cases would be a nice type-checker job, e.g. for the sicp/solver.
- nickpsecurity 10y ago
  Ok. There we go. It's actually what I had in mind for PreScheme. You just gave me more confidence in it.