[1] https://github.com/duangle/scopes/commit/13255e0ae7ab76e070c...
But http://scopes.readthedocs.io/en/latest/about.html says "The memory model is compatible to C/C++ and utilizes simple unmanaged stack and heap memory." And I do recall paniq tweeting about wanting to implement a Rust-like system for memory management, because how hard can it be? (Fortunately, it doesn't look like he ever tried it.)
In addition, https://bitbucket.org/duangle/scopes/wiki/Home contrasts "expressivity of Scheme" and "the performance and runtime model of C" as if the developer did think of these as opposites.
It's very old code from two years ago, when the language was still being prototyped. I did have a form of GC for a while that I threw away again because I couldn't make it work right.
I recommend not taking any commits before the first tagged release seriously.
> Fortunately, it doesn't look like he ever tried it.
I tried, but I'm completely paralyzed here. As long as I can't see a straightforward way to integrate support into the typechecker, I won't write a single line.
Also, why "fortunately"?
> as if the developer did think of these as opposites
Not opposites, just not aligned with each other. The demands of Scheme's runtime model inherently conflict with realtime performance. There's nothing wrong with that, but that sets it apart from C.
With this sentence, I hoped to address Scheme users who wish they could generate faster, tightly-constrained assembly while not having to give up on hygienic macros and nested evaluation contexts. No insult was intended.
Because I think it's a lot harder (both for you and for your users) than you thought at the time, and I hoped you wouldn't waste your time (and your users' time) on it. Personally, I think GC is the way to go to keep your (programmers') sanity. If you worry about GC pauses in time-critical sections, provide for a way to turn off the GC temporarily for such sections.
You might want to mark such non-GC sections/functions specifically and enforce statically that no dynamic allocation may be triggered from within them. Kind of like a monad. No allocations, no GCs, no headaches. Simpler and more flexible than the Rust model.
> No insult was intended.
I didn't read that as such!
Scopes has no garbage collection. There will be garbage collection for compile time symbols at some point, but the runtime is completely manually managed. That is a big difference to Scheme, although Scheme has been a major influence to Scopes design, and features that I believe to set Lisp/Scheme apart from other languages have been adopted.
Scopes is statically typed, but type signatures are not elementary to function definitions and value declarations, as with Scheme. It is a little limited with its compile-time closures though, whose application as first class values is limited.
