[tom_mellior]

That code does indeed automatically delete some entries from some collection, and it does use garbage collection terminology, but it doesn't appear to be full garbage collection for the whole language. Hard to tell in the complete absence of comments and a commit message.

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.

[paniq303]

> That code does indeed automatically delete some entries from some collection, and it does use garbage collection terminology, but it doesn't appear to be full garbage collection for the whole language. Hard to tell in the complete absence of comments and a commit message.

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.

[tom_mellior]

> Also, why "fortunately"?

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!

[paniq303]

> 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.

I believe it is possible to offer such a feature without declarative baggage. If it's not, then I don't want 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.

It might be even possible to leverage Scopes' support for compile-time introspection to write contextual GC's from within the language. I haven't explored that yet. In games development we usually prefer to allocate in frames, stages or on custom stacks, so that's also a way to do it.

Installing a GC at the lowest level is a brutal choice that precludes many other possible ways this could go, so I'm cautious.

[yoklov]

FWIW, I’m in the camp of people who find this to be extremely interesting, but only given that there’s no GC.