[nextos]

Yes, Chez & Stalin are the fastest in these benchmarks, which seems to match what the community usually answers when asked about quick implementations.

Sadly Stalin is unmaintained. Its whole program optimization techniques were really advanced. I remember it even got my ivory-tower professors, who were big in the static analysis field, excited.

Now, a tricky question. I'm mostly unfamiliar with Scheme for writing real-world code. Will the ongoing merger of Chez with Racket make the latter a clear winner in the Scheme camp? How are libraries and FFI?

A problem with Scheme is excessive fragmentation. Having a clear winner would be cool for library support. Racket is great due to multiple paradigms and DSLs [1]. I hope it eventually becomes a very practical Lisp with all Mozart/Oz semantic goodies.

I am trying to do all my projects in a Lisp. Lately this is either Clojure or SBCL. Both have good libraries and decent FFIs. Clasp (Common Lisp on LLVM) [2] has gotten me excited, as good interfacing with C++ will be great to access a lot of quick numerics code.

[1] https://beautifulracket.com/appendix/domain-specific-languag...

[2] https://github.com/drmeister/clasp

[baldfat]

> Will the ongoing merger of Chez with Racket make the latter a clear winner in the Scheme camp?

Academically they have all the super giants of Scheme. It is now within the past few years with the renaming to Racket that the success story is just now unfolding after over 20 years of development. I think Racket will end up being the clear leader not just of scheme but of Lisp. Reminds me of when R just took off 5 or 6 years ago.

[nextos]

That would be amazing. I think the issue with Scheme, and in general most Lisps has been excessive fragmentation.

[kovrik]

> A problem with Scheme is excessive fragmentation.

Yes. And not only that, but also the fact that each Scheme implementation is slightly (at best) different from all other implementations. I guess that is because Scheme standards are not that strict (for example, compare with Java specs)

[dleslie]

They're fairly strict; if you code to RnRS and use only SRFIs then you'll find your code to be fairly portable... And nigh-useless.

The problem with the Scheme standards is that the committee refuses to be opinionated about implementation details, and so the standard is defined in terms of itself with little to no consideration for the environment in which Scheme will operate. In practical terms, this means that if you want to communicate with other libraries, or virtually any aspect of the system on which you're running, then you're venturing outside of the Scheme specification and into implementation-specific territory.

Scheme is a toy language. The implementations are not, but then they aren't Scheme so much as they are Scheme with useful extensions.

[kovrik]

I don't know, every time I check different common implementations (Racket, Guile, Chicken, Chez, Kawa) - they all act very different. Very often even a very simple code snippet works fine in one implementation, but not in the other(s).

And while writing my own Scheme, I literally had to choose "Ok, I will implement this Racket-way; This I will implement Guile-way" etc.

[Johnny_Brahms]

I have found that you fairly easily can write portable r6rs code, but whenever you step outside r6rs (for stuff that isn't standard, like networking) it becomes an exhibition of cond-expand abuse.

[ClFromEmacs]

R7RS ftw.

[Johnny_Brahms]

I feel that not standardising a low level FFI for r7rs large is a mistake. They should at least recommend some reasonably low level stuff that can be used to build abstractions.

[cat199]

Agree with the sentiment, but at the same time understand the rationale - FFI implies alot of GC/memory internal interfacing stuff, and to some extent expects a c-based implementation (not e.g. JVM,CLR,etc).

If r7 & library interface are widely adopted, some flavors of FFI could evolve within the library/srfi process and gradually become defacto standards..

Probably hoping too much.. but in any event..

[dleslie]

That didn't happen with R5RS, why would it happen now?

Face it, by refusing to be opinionated they ensured Scheme will remain a toy.

[Johnny_Brahms]

Because r7rs large is an effort that probably is bigger than common lisp. It is very much not a toy language.

[dleslie]

If it doesn't have an ffi it will remain a toy that relies on implementations to make it useful.

[Johnny_Brahms]

I think that the best way to go about it (at least if you want to be successful) would be to write a SRFI that could easily be impkemented using the FFIs that are already out there.

Managing that, but still being flexible enough to be useful, is a huge amount of work, at least if you want to do more than just "call this c function".

[ClFromEmacs]

http://snow-fort.org/link/ very portable packages that are quite complete. R7RS provides for portable code.