TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Crunch – a Scheme compiler with a minimal runtime

190 点作者 sjamaan5 个月前

13 条评论

fouric5 个月前
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&#x2F;object code, CRUNCH is additionally targeting a <i>statically-typed</i> subset of Scheme.<p>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.
评论 #42445557 未加载
评论 #42442772 未加载
评论 #42442970 未加载
评论 #42442377 未加载
rollcat5 个月前
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.<p>Notable is the lack of call&#x2F;cc, but in my &quot;armchair expert&quot; opinion, it&#x27;s the ugliest part of the language. Yes, continuations as a first-class object are elegant and succinct, but in order to do anything <i>actually useful</i> with them (like implementing exceptions), you need library code, which makes them much less composable.<p>I think there&#x27;s a much more pleasant and practical language lurking somewhere between R6RS &quot;big&quot; and traditional &quot;small&quot; Scheme, but I feel it would take a BDFL to flesh it out.<p>(Meanwhile, back to fixing my init.el.)
评论 #42442426 未加载
iainctduncan5 个月前
This just made my day. I&#x27;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&#x2F;tco&#x2F;etc.<p>I will be watching this closely!
评论 #42446693 未加载
评论 #42442937 未加载
davexunit5 个月前
I&#x27;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.
ta86455 个月前
The very first rudimentary standalone example:<p><pre><code> (define (main) (display &quot;Hello world\n&quot;)) </code></pre> Doesn&#x27;t compile, but instead gives error:<p><pre><code> Error: main: global variable `scheme#display&#x27; has unknown type</code></pre>
评论 #42443194 未加载
VyseofArcadia5 个月前
I believe the domain name is a reference to this anecdote <a href="https:&#x2F;&#x2F;www.catb.org&#x2F;jargon&#x2F;html&#x2F;magic-story.html" rel="nofollow">https:&#x2F;&#x2F;www.catb.org&#x2F;jargon&#x2F;html&#x2F;magic-story.html</a>
评论 #42448749 未加载
JonChesterfield5 个月前
&gt; Other targets are possible, like GPUs. I don&#x27;t know anything about that, so if you are interested and think you can contribute, please don&#x27;t hesitate to contact me.<p>The freestanding macro suggests most of the heavy lifting is done. Stuff the GPU targets will struggle with in no particular order:<p>- setjmp &#x2F; longjmp<p>- signals (if used?)<p>- threads<p>- fast alloc&#x2F;free<p>- stack will be smaller than chicken expects<p>I don&#x27;t know how to do signals. The rest are merely difficult.
评论 #42448754 未加载
评论 #42444411 未加载
nudpiedo5 个月前
so if I understand this right, it could be a way to run scheme on esp32 and similar microcontrollers, isn&#x27;t it?<p>Also its small size would make it a perfect target to compile to typescript&#x2F;deno&#x2F;wasm without rejecting the s-exp power and runtime possibilities in its full chicken code at the backend...
评论 #42441030 未加载
评论 #42441270 未加载
评论 #42440943 未加载
soegaard5 个月前
The documentation for Crunch is here:<p><a href="https:&#x2F;&#x2F;wiki.call-cc.org&#x2F;eggref&#x2F;6&#x2F;crunch" rel="nofollow">https:&#x2F;&#x2F;wiki.call-cc.org&#x2F;eggref&#x2F;6&#x2F;crunch</a>
jxy5 个月前
&gt; No support for first class continuations<p>I&#x27;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?
评论 #42444731 未加载
评论 #42442323 未加载
评论 #42442283 未加载
评论 #42444167 未加载
JonChesterfield5 个月前
The make &amp;&amp; make install doesn&#x27;t create the chicken-crunch executable which is used in the examples, nor do I see &#x27;crunch&#x27; in any of the build scripts. Any guesses?
评论 #42442231 未加载
Imustaskforhelp5 个月前
Interesting since this can compile down to C code , I was thinking maybe we can convert this to cosmopolitan c code as well?
评论 #42442754 未加载
评论 #42441748 未加载
hassleblad235 个月前
This looks useful for sure.