https://ccrma.stanford.edu/software/snd/snd/s7.html
A flexible, small scheme that can be added to C programs and provides lots of features. How does /prog/ feel about it?
cond-expand is dumb and its name is dumber. Take libgsl.scm; different versions of the GSL library have different functions. We need to know when we're building the FFI what GSL version we're dealing with. It would be nuts to start pushing and checking dozens of library version symbols when all we actually want is (> version 23.19). In place of cond-expand, s7 uses reader-cond, so the read-time decision involves normal Scheme evaluation.
meh
I don't really like the concept of chicken scheme, this isn't making it better.
>>3
The dirty imperative Cee has a long history of being used as host for pure functional languages, because its flexible, portable and fast. The C FFI and libc api are cornerstones of modern computing, despite being quite ancient.
>>4
Ansi c89 is not flexible imo but it's portable and fast depending on how you use it. Not denying new jersey was chosen over phd mit but if no enthusiast routes are used, then you can never expect a practical one. New jersey is practical due to historical authority and adoption over alternatives. That doesn't legitimise a language to language compiler for practically when there's already a language to machine code toolchain that's even more portable and with ffis available. S7 scheme is far past the need for a chost, except there are better optimised toolchains that are written in c++11 and above since that's where all the working engineers are that would even take consideration of s7 in this day and age. Depending on superoptimisation studies toolchains may no longer be a engineer resource problem. Allowing the scheme toolchain to be bootstrapped off chosts from ancient unmaintained toolchains 10 people at most will use but still appreciate the convenience.
s7 won't appeal to scheme purists, but it is very lightweight, spare on dependencies, and fit for purpose (imo) for what it was designed to do. for many projects, Chicken is just overkill. I remember finding it comfortable to use for Snd.
I've never used scheme before, I've only looked it up to see whether it's worth using as my scripting language for prototyping and systems administration. I've read about the scheme reports and various implementations.
I felt that the implementations are rather more important than the reports themselves, talking about r5rs and r6rs, however none of them seem too mature to get into? Example, all features are mainly documented as a Manual and not offered to user through proper documentation and/or tutorials (if you wish to call it that way). It keeps the newcomers away.
Recently I watched https://www.youtube.com/watch?v=3ndZcd3-9hw and I noticed that Andy Wingo, known for Guile, expressed his "unwillingness" to contribute back and implement r7rs. From my research, Guile is a pretty mature Scheme implementation however there is no straightforward introductory to the language itself or to Guile-specific features other than the reference manual.
The design of r7rs, from the perspective of a newbie, seems very modular and interesting. I wish that it becomes widely popular among Scheme users for a united ecosystem.
My words are unwise and only notes, sorry for any misunderstanding of misinformation.
>>7 Well, that was 3 years ago. I think Guile 3 is r7rs compliant now- at least you can do:
>(import (scheme base))
>(features)
$1=(... r5rs r6rs r7rs ....)but to be fair to Andy, I have seen plenty of people on the mailing list saying they needed features from 1.8 for, say Lilypond, and I believe it has debugging features the versions after it don't have.