The interesting part is how few trade-offs had to be made to make GC-less (ref-counting) Scheme-to-C compilation attainable, and how closely CRUNCH adheres to R7RS.
Notable is the lack of call/cc, but in my "armchair expert" opinion, it's the ugliest part of the language. Yes, continuations as a first-class object are elegant and succinct, but in order to do anything actually useful with them (like implementing exceptions), you need library code, which makes them much less composable.
I think there's a much more pleasant and practical language lurking somewhere between R6RS "big" and traditional "small" Scheme, but I feel it would take a BDFL to flesh it out.
(Meanwhile, back to fixing my init.el.)
This just made my day. I'm the author of Scheme for Max, an extension to the Max music programming environment that puts the s7 Scheme interpreter in it for scripting note-event level code (not dsp). It would be fantastic to also be able to use a subset of Scheme for generating DSP level code, where speed would be more important than dynamic typing or continuations/tco/etc.
I will be watching this closely!
I'm glad to see more projects exploring the statically compiled Scheme space. One difference from PreScheme listed is R7RS conformance, but the PreScheme restoration project is also targeting R7RS so that the compiler is portable to many Scheme implementations. The biggest difference I can see is manual memory management vs. reference counting. Though, one of the TODO items for the PreScheme restoration is to revisit memory management. Maybe PreScheme will end up with reference counting, as well.
The very first rudimentary standalone example:
(define (main) (display "Hello world\n"))
Error: main: global variable `scheme#display' has unknown typeI believe the domain name is a reference to this anecdote https://www.catb.org/jargon/html/magic-story.html
> Other targets are possible, like GPUs. I don't know anything about that, so if you are interested and think you can contribute, please don't hesitate to contact me.
The freestanding macro suggests most of the heavy lifting is done. Stuff the GPU targets will struggle with in no particular order:
- setjmp / longjmp
- signals (if used?)
- threads
- fast alloc/free
- stack will be smaller than chicken expects
I don't know how to do signals. The rest are merely difficult.
so if I understand this right, it could be a way to run scheme on esp32 and similar microcontrollers, isn't it?
Also its small size would make it a perfect target to compile to typescript/deno/wasm without rejecting the s-exp power and runtime possibilities in its full chicken code at the backend...
The documentation for Crunch is here:
> No support for first class continuations
I'm not sure about how people would feel about this. I have mixed feelings. It feels like a loss of many things. What are the gains from ditching continuations?
The make && make install doesn't create the chicken-crunch executable which is used in the examples, nor do I see 'crunch' in any of the build scripts. Any guesses?
Interesting since this can compile down to C code , I was thinking maybe we can convert this to cosmopolitan c code as well?
This looks useful for sure.
For Common Lispers such as myself, who are vaguely aware of developments in the Scheme space: the most important difference between CRUNCH and Chicken appears to be that, while both compile down to C/object code, CRUNCH is additionally targeting a statically-typed subset of Scheme.
Opinion: this is great. The aversion of Lispers to static types is historical rather than intrinsic and reflects the relative difference in expressiveness between program semantics and type semantics (and runtime vs tooling) for much of computing. Now that types and tools are advancing, static Lisps are feasible, and I love that.