Re: Trying to understand chicken limitations

[Marc Feeley]

Marc



> On Dec 24, 2019, at 10:15 AM, cesar mena <address@hidden> wrote:
> 
> Lassi Kortela <address@hidden> 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