21–30 of 73 posts
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 excep…
> 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?
From the article: > What is needed is a small, portable compiler that generates more or less "natural" C code with minimal dependencies and runtime system that supports at least the basic constructs of the language and that puts an emphasis on producing efficient code, even if some of the more powerful features of Scheme are not available. Since C doesn't support continuations, it is not possible to have continuation…
Since CHICKEN actually does this, I'll add the proviso of "without a GC or costly runtime".
I will be watching this closely!
Interesting since this can compile down to C code , I was thinking maybe we can convert this to cosmopolitan c code as well?
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?
The installation bit mentions doing: > /bin/chicken-install -test crunch Edit: That's because this is an "egg", which is an external library/package not part of the core chicken install
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…
Haven't that been feasible for a pretty long time already? Judging by how well-received (or not) they've been, it seems there isn't much demand for it. Things like clojure.spec and alike (compile-time + run-time typing) seems much more popular, but isn't static.
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 excep…
Delineated continuations might help
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!
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…