Marc
> On Dec 24, 2019, at 10:15 AM, cesar mena <[email protected]> wrote: > > Lassi Kortela <[email protected]> writes: > >>> As for S7, I would use Chibi instead: it's more modern and probably faster. >> >> It's a little-known fact that S7's author, Bill Schottstaedt still >> actively maintains it (https://ccrma.stanford.edu/software/s7/). S7 is >> the scripting language for three audio/music programs: Snd, Radium, >> and Common Music. No matter which Scheme implementation you end up >> using, you may be able to bounce ideas off Bill, or ask him about who >> you should talk to about Scheme and Max. He is from the academic music >> community; with luck, he may even know somebody who has already used >> Scheme with Max. The Snd subversion repository (at SourceForge, linked >> from that page) has some S7 Scheme code for various audio tasks. You >> may be able to repurpose it for Max, and with some work also for >> Scheme implementations other than S7. >> >> S7 is a heavily modified version of TinyScheme, which itself is a >> heavily modified version of the venerable Mini-Scheme dating all the >> way back to 1989. Mini-Scheme is an awesome feat of C coding - a >> Scheme interpreter with proper lexical scope and tail calls in only >> 2000 lines of C. However, it would be too bare-bones for your >> needs. TinyScheme may be enough, but S7 would probably be better since >> it has already been used for music. >> >> TinyScheme should be fully re-entrant so it can be used in a >> multi-threaded C program. All of the interpreter state is stored in >> one C struct; you can make as many interpreters as you like and run >> each one in a different thread. I'm not sure whether or not S7 is >> re-entrant. >> >> IIRC, TinyScheme (or a slight derivative of it) is the current >> scripting language of the GIMP image editor. >> >> All of these Schemes start up instantly and due to their simplicity >> are the easiest to embed into C with no external dependencies. Their >> internals are easy to modify as needed. But they are also the slowest >> interpreters available. They don't even have a bytecode compiler; they >> store your procedures as lists and recurse through the lists each time >> you call the procedure. Chicken, Chibi-Scheme, etc. have bytecode >> interpreters that are almost certainly faster if your Scheme code has >> loops with lots of iterations. However, they are also more complex. > > this is off-topic, but i'm very curious about this. i would really > appreciate any feedback. > > is a bytecode interpreter faster (all things being equal) than one which > stores procedures as lists? even with loops and iterations, assuming > the code was was only lexically analyzed once as in "The Structure and > Interpretation of Computer Programs"? > > i would think the eventual speed of a byte compiler comes from all the > optimizations that are possible. A well designed bytecode compiler should be faster than a plain S-expression walking interpreter, because the bytecode can benefit from code transformations and optimizations, and also the instruction dispatch is on numbers (the opcode) rather than a kind of pattern matching on S-expressions (dispatch on symbols). But for an even faster approach there is closure compilers (which is related to threaded code): http://www.iro.umontreal.ca/~feeley/papers/FeeleyLapalmeCL87.pdf Marc
