Hi,<br><br>I am collecting ideas for my personal summer of code :-) Before leaving on the 3rd of July (I will be not so reachable until the 21st) I will try to make the last 0.9 release. Afterwards I want to work on stability and getting the first 
1.0, but that should have something special with it.<br><br>* Unicode. This seems to be en route with Brian's changes.<br><br>* Compiler fixes. I will spend at least august using Paul Dietz's random tester to try crashing ECL in all possible ways. 
1.0 will not come until we get rid of all current compiler bugs.<br><br>* Documentation. People may help here. Nothing big is expected. It would be enough if somebody has a look at the manuals and reorganizes them, dropping out all information which is already in the Hyperspec, creating a section for ECL-specific behavior, another section for extensions, incorporating the docs about multithreading, etc.
<br><br>* Interpreter. Some time ago I managed to speed up the bytecodes interpreter and compiler by 20%. Those changes are lost (*). I would need some time, but basically I reorganized the bytecodes, simplifying some, and adding extra flags and two registers. Also, perhaps we should focus on a more compact representation of bytecode functions.
<br><br>* Calling conventions. This is something that I have in mind since I first worked on ECL. The ideal goal would be to be able to call functions directly, via a pointer, but with a portable implementation. I have been thinking on a scheme like
<br><br>struct ecl_cclosure {<br>    HEADER;<br>    cl_object (*function)(int narg, ...);<br>    /* data goes here */<br>};<br><br>All funcallable objects would have this structure and add their own fields. Calling a funcallable objects amounts then to 1) set a global variable with a pointer to the closure, 2) call directly the function. This avoids having to push arguments on the stack. Functions with a fixed number of arguments would have a similar structure
<br><br>struct ecl_cfun {<br>    HEADER;<br>
    cl_object (*function)(int narg, ...);<br>
    /* data goes here */<br>   
cl_object (*true_fun)();<br>    cl_object name;<br>}<br><br>Bytecodes would also be closures, and generic functions as well. I would like to get feedback on this topic. My only concern is the global variable containing the closure data. It seems like it could have a significant overhead in multithreaded lisps. But perhaps there are tricks, like thread-local variables, which would help. And maybe the overhead is way smaller than current use of funcall() and the lisp stack.
<br><br>Juanjo