Re: Trying to understand chicken limitations

[cesar mena]

Marc Feeley <address@hidden> writes:

> 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

awesome paper! you answered all my questions. thank you for
sharing. execution times of 2-4x the host language is really impressive!
wow!  you must have been surprised.  why is this technique not used
more? (or maybe it is?) was gambit at any point this kind of compiler?

you mentioned that the method should be possible with any language that
possess closure or their equivalent but don't mention C; but surely one
can emulate them in C no? and have an embedded language that is possibly
simpler to debug? methinks this idea has more to give :)

cheers!

-cm