Why S7 Scheme? (2020) | Hacker News Reader

Why S7 Scheme? (2020)

iainctduncan.github.io

84 pointsbmacho18 comments

I'm grateful for the author's "other options that were considered" section with eight alternatives to S7. But Embeddable Common Lisp (ECL) is the only one listed that he doesn't write a few sentences about, to contrast its pros and cons versus S7. I'd love to hear more.

clang and ECL both seem interesting, as long as LGPL license is ok. They both are complex to embed though - neither are well tuned to be embedded in other applications. (I've been exploring on MacOS). Julia could be interesting too under same questions (and a better license for commercial products) but similarly has a fair bit of glue code needed - especially if you want to restrict (say) filesystem access.

Oh right, that was a thing too. LGPL would have complicated some plans. Forgot that details.

OP: it was a two factor decision.

The first is that it seemed at the time that Scheme was going to be easier to work with, and that has proven true. It's a lot easier to do music theory hacking and integrate with Max using a lisp 1. Being able to seamlessly change whatever the first form is (function, hash-table, list, vector) with no change to the code has turned out to be really really nice in my work.

The second was that when I started I knew little about Schemes and Lisps and it seemed when going through the docs like ECL at that time was going to be a bigger lift to get going.

Solid reason, thank you. Yes, Lisp 1 for the win in many cases.

Now... there's also the wonderful Fennel possibility which distracts me when I'm bikeshedding. ;-)

Yes, Fennel is a great distraction (see my other post)!

S7 is very cool indeed. It also comes as a single C file, which makes it easy to embed.

As a CHICKEN maintainer, I'd love to hear what the author was missing in the FFI part of the manual.

Hmm, it's been a while. It was partly the fact that it was not as simple as s7, and also was complicated a bit by the compiled-to-C nature of Chicken. I did really like what I saw in Chicken though.

In the FWIW department, my (tiny indie games) company shipped several apps based on S7 that ran cross-platform on iOS & Android (together with SQLite). We used native UI, but had a common Scheme S7 core that had the game and database logic. It was marvelous for succinct code, fast running tests and really helped slim down duplication across our previously completely native apps. The "single C file" was critical to our choice, as, like SQLite, it enabled us to easily integrate with the native iOS & Android tooling without setting up byzantine build processes.

We also used Guile during the desktop-based development process for sometimes better debugging and to enforce greater R7RS code-compatibility. (Ah, and the subtle bugs of alternative function parameter evaluation order!)

We later moved to Fennel(-lang) based on Lua as it was a slightly better fit for our team in various ways, but the S7 experience, including the community, was fantastic!

Both solutions proved stable with tens of thousands of monthly active players.

Nice, I was going to mention that there had been several game devs on the mailing list, thanks for sharing.

The single C file convenience really is helpful. When I was figuring out the byzantine build process for incorporating s7 into a mixed JS, C, Scheme app, it was great to not have any additional foot guns there. On my eventual todo list is porting some of the same work to incorporate into JUCE apps for mobile, so good to know that worked for you.

Fennel is another language I have been watching, good to hear that worked out well.

I have found S7 scheme to be a delight to use as a configuration/extension language. I find it much more intuitive then something like Lua or even embedded python. Because of its heritage, most of the s7 scheme uses I've seen online are music related, but it really shines outside of that field as well.

yes, it really is. In my music pedagogy project I use it as the domain layer via WASM sitting between JS and C/C++ audio workers. It's been great that way.

Author here! Funny to see this arise now, I shared links to the project a number of times but never got much interest here. For what it's worth, I would (and should!) update that page, but the choice of s7 has worked out really well. I now also use it in a WASM context, which is great. The fact that I can easily use the same scheme implementation anywhere I can run ANSI C has proven to be a real advantage.

Happy to answer other questions.

For people interested, I will update that page today with thoughts five years on.

TLDR: still really happy with the choice!

Is there a SLIME-equivalent to achieve REPL driven programming for applications with s7 embedded in them?

That I don't know, but the s7 author, Bill Schottstaedt (who I will ping about this) is very helpful on the email list and is deeply, deeply knowledgeable about Lisp, so you could definitely ask there!

https://ccrma-mail.stanford.edu/mailman/listinfo/cmdist

In my context, I have rigged up a REPL in Max, so I wind up using that instead. (Which is freaking awesome, because I can script all of Max from my vim buffers.)

it's trivial to implement a REPL yourself, you "just" need to poll for stdin in your main loop and pass this to S7 for evaluation. I made a demo once upon a time live coding with DearImGui: https://www.youtube.com/watch?v=MgHsl0u26MY

For the emacs side I used cmuscheme which is basically comint. Of course you don't get the same experience as in common lisp, but I found S7 to be pleasant to work with also in regards to reporting errors etc

(2020)

Added. Thanks!

Reply on news.ycombinator.com