Also, that makes it hypothetically possible that HN could end up running on Chez's VM because HN is written in Arc, which is I believe written in Racket, which may in the next year be written for Chez Scheme's VM.
The puzzle benchmark is nice, since it benchmarks many common compiler optimizations - with code written to be easily optimized. Stalin of course wins.
The other benchmarks are written in a more general style, which I have found does not always produce the best output with stalin. If I would spend some time optimizing these benchmarks, I could probably make Stalin come out on top a lot more often.
That, however, takes you are back to the old problem: A heavily optimized C program looks like C. A heavily optimized [insert functional programming language here. Most often haskell] program looks like shit.
What impresses me the most about chez is that it takes idiomatic scheme code, and produces neat and fast machine code.
Really? I haven't found that to be the case very often.
> A heavily optimized [insert functional programming language here. Most often haskell] program looks like shit.
Here we definitely agree :). It's also worth mentioning that it's not often worth it to optimize very much of your code. (The 80-20, or perhaps 95-5, rule applies in full force.)
Obviously, it's still worth it to have compilers optimize idiomatic code.
Not in the 80's and early 90's.
What C has, is 40 years of development effort invested by several multinationals with deep pockets and researchers, improving the optimizer algorithms of their compilers.
Looking at older C code is still better than seeing the hoops people jump through to get [insert programming language] to run at regular C speeds.
Fast C usually doesn't include weird workarounds for things like Implementation-specific GC quirks or bending language semantcs to force it to do what you want.
naked void my_C_func()
{
asm {
...
}
}
There were also other tricks related to unions and bit fiddling.
In those days, on 8 and 16 bit home computers, C was seen like managed languages are nowadays.
Couldn't that be explained by observing that C looks like shit, and we've just gotten so used to the look (and the smell!) that we fail to notice?
Not sure if that's still true, but AFAIK all work on arc has been stalled for quite a while.
It works with the latest Racket versions and includes a HN clone. You can see it running here: http://arclanguage.org/forum
It's true that pg isn't working on it though. I wonder if he's ever getting back to it.
Depending on how portable Arc is to new versions of Racket, I'd guess they could move to a new Chez-backeneded Racket without any need to port.
The moment another language gets used, like C, there is this misunderstanding among compiler design illiterates that without the use of that programming language, writing the compiler wouldn't be possible at all.
https://en.m.wikipedia.org/wiki/PreScheme
Only C in one of the implementations was an I/O shim for the C-based OS. That could be removed for purity but they were about pragmatism.
So, not as nice as a full Scheme but great in other ways and used to write a Scheme.
It differs from T in that the VM is written in a different scheme dialect than the VM hosts, but it is still as much scheme-all-the-way-down as T was. It's also considerably safer than T as it will prevent you from doing some unsafe things and warn you about others (e.g. run-time closures).
I though about a new incarnation of PreScheme. One would add memory safety like Rust's borrow checker. Carp LISP is already doing that. Another was to embed a version of C in it amenable to static analysis and KLEE-like tools with actual coding in Scheme with macros. Last was reviving VLISP using Magnus Myreen's LISP 1.5 or CakeML tools to verify it from LISP form to machine code. Then we'd have a semi-verified Scheme48 where you just trust the high-level code essentially.