If anyone is looking for benchmarks, the most comprehensive comparison of scheme implementations can be found here: http://ecraven.github.io/r7rs-benchmarks/benchmark.html

Wow, Chez mostly beats out Stalin.

If we look at the benchmarks where one can expect stalin to be fast (numeric, and more specifically floating point benchmarks.) stalin is really in it's own league.

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.

> A heavily optimized C program looks like C.

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.

> A heavily optimized C program looks like C.

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.

Well. Fast c doesn't look quite like regular C, but seeing C optimised for speed isn't rare.

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.

No, fast C in the 80's and early 90's meant writing code that was actually like this:

    naked void my_C_func()
    {
      asm {
       ...
      }
    }

Which basically meant using C as a poor man's macro assembler and nothing to do with what ANSI C is.

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.

I see what you mean. I never did those gigs, so I wouldn't know. In hindsight I don't regret it :)

> 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.

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?

Let me rephrase: for some types of problems it is easier to use an imperative language, because it is easier to express the fastest way of doing it imperatively.

The last time I checked, arc required a pretty old version of racket that supported mutable cons cells.

Not sure if that's still true, but AFAIK all work on arc has been stalled for quite a while.

There's a community version of the language being developed here: https://github.com/arclanguage/anarki

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.

I'm not sure if its super important that PG gets back to it. To be honest, I'd love if someone made a summary of what, in 2017, makes arc unique and worth looking into.

FWIW Racket has two types of cons cells: mutable and immutable. And if you know what you are doing - then you can abuse the FFI to mutate the immutable ones (but don't tell anyone) using unsafe-set-mcar! and unsafe-set-mcdr!.

I think it may be faster to just port, though are there larger libraries that Arc depends on in Racket that you'd also have to significantly port?

I honestly have no idea. I think I remember reading that Arc may also be pinned to a somewhat old version of Racket / PLT Scheme. I could be misremembering though.

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.

Arc works fine on newer versions of Racket using the MzScheme legacy language bindings.

Is Chez "scheme all the way down"?

The only "scheme all the way down" implementation I know of is T. It's just too much of a pain to fully self-host the garbage collection code, and it's not exactly clear what the gain of doing so is.

The satisfaction of not depending on anything else other than some Assembly.

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.

PreScheme:

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.

Well, that deleted comment was one of most respectable I've seen in a while. You were accurate about its features but maybe missed the justification: it was a replacement for C in terms of low-level use and performance (ideally). That made typical Scheme features impossible. Additionally, it was a critical part of VLISP project to mathematically verify a Scheme (Scheme48). They had to balance power and complexity carefully. So, it was efficient, gave you some Scheme power, and mathematically verified for correctness at the algorithm level for VLISP version.

So, not as nice as a full Scheme but great in other ways and used to write a Scheme.

I deleted it because I realized it was nonsensical. The T garbage collector was written in a subset of T, which is not a strict-subset of Scheme, as it uses system-level features.

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).

Yeah that's about it. T was interesting too. I discovered it looking for PreScheme stuff actually. Jonathan Rees was involved in both with pg writing a T essay. So Google led me to it. The info on it looks to scattered for me to study easily like I did with PreScheme's all in one place stuff.

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.