Doh! Hit send before I was done.
On 3/1/2019 11:50 AM, Curtis Dutton wrote:
Now I find myself wondering, why can't racket run in realtime? The GC is the most obvious hurdle that I can see. But racket execution speed by itself is plenty fast enough.
There are a number of reasons: Racket's virtual machine model, the GC, the fact that Racket (currently) does not compile AOT to native code, but rather JITs at runtime, the fact that Racket does not allow hardware access, etc. The TL,DR is that Racket wasn't ever designed with realtime execution in mind.
Most of these are not fixable without a complete rewrite. Racket-on-Chez changes the virtual machine model, and addresses the AOT compile issues, but the others remain.
So what I'm looking for is a racket language that doesn't generate garbage at execution time. But a "setup" phase could do so and it wouldn't be a problem.
You could create a variant that ignored garbage - like Javacard - but creating a Lisp/Scheme variant that didn't *create* garbage in the first place is a lot harder. Such a language would have to give up 1st class closures. Do you remember using Pascal's function parameters?
A realtime quality GC is an enormous project. It might be easier to replace the GC with region based memory management. Regions aren't completely immune to garbage, and a long running application does need GC as a fallback - but the GC in a mostly region system can be very low priority.
Is there such a thing? Is it worth pursuing? Or better to just stick with C?
You could look at Pre-Scheme, or PicoLisp, or Yalo. But any Lisp/Scheme that is suitable will have significant limitations. For hints at what you'd be giving up, look at the restrictions on "realtime" Java.
George -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
