6 ms·

https://ecraven.github.io/r7rs-benchmarks/ https://ecraven.github.io/r7rs-benchmarks/ recent addition to the charts, and is doing quite well.

nextos 9y ago
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-languages.html https://beautifulracket.com/appendix/domain-specific-languag... [2] https://github.com/drmeister/clasp https://github.com/drmeister/clasp
- ClFromEmacs 9y ago
  R7RS ftw.
  - Johnny_Brahms 9y ago
    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 9y ago
      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 9y ago
        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 9y ago
        Because r7rs large is an effort that probably is bigger than common lisp. It is very much not a toy language.
        dleslie 9y ago
        If it doesn't have an ffi it will remain a toy that relies on implementations to make it useful.
      - Johnny_Brahms 9y ago
        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 9y ago
    http://snow-fort.org/link/ http://snow-fort.org/link/ very portable packages that are quite complete. R7RS provides for portable code.
- kovrik 9y ago
  > 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 9y ago
    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 9y ago
      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 9y ago
        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.
- baldfat 9y ago
  > 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 9y ago
    That would be amazing. I think the issue with Scheme, and in general most Lisps has been excessive fragmentation.

nextos 9y ago

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-languages.html https://beautifulracket.com/appendix/domain-specific-languag... [2] https://github.com/drmeister/clasp https://github.com/drmeister/clasp

ClFromEmacs 9y ago
R7RS ftw.
- Johnny_Brahms 9y ago
  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 9y ago
    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 9y ago
      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 9y ago
        Because r7rs large is an effort that probably is bigger than common lisp. It is very much not a toy language.
        dleslie 9y ago
        If it doesn't have an ffi it will remain a toy that relies on implementations to make it useful.
    - Johnny_Brahms 9y ago
      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 9y ago
  http://snow-fort.org/link/ http://snow-fort.org/link/ very portable packages that are quite complete. R7RS provides for portable code.
kovrik 9y ago
> 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 9y ago
  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 9y ago
    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 9y ago
      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.
baldfat 9y ago
> 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 9y ago
  That would be amazing. I think the issue with Scheme, and in general most Lisps has been excessive fragmentation.