Hi Alex, > >you cannot do TCE while interpreting List structures. You have to > >do it in the compiler, as it requires some analysis of the code > >structure. > One could always look ahead and try to analyse the s-expression's > structure while executing it... this probably wouldn't perform very > well though.
Yes, exactly. That's what I meant. It somehow violates the idea of the interpreter. It wouldn't perform very well, but it would of course solve one issue you mentioned before: The stack overflow. > I think we are thinking the same thing, just from different > perspectives :). You could conceivably write an interpreter for pure > list data that eliminated tail calls, because you can write an > interpreter that can do anything, but it wouldn't be an optimisation > because of the extra overhead. True. > >PicoLisp. PicoLisp has "dynamic binding". > ... > Still, using the correct term, unless I'm gravely mistaken the > presence of it necessarily forbids one from even considering general > TCE, as it would demand messing with the bindings at the wrong > times. To my understanding, this would not be a problem. Given that we take the trouble of making the interpreter TCE-able, it could probably manipulate the symbol bindings too, by 'setq'-ing them to new values instead of 'bind'-ing them (saving their values to the stack before setting them). To my feeling, TCE would be very inappropriate for PicoLisp, as it is rather against the "spirit": It makes things complicated, does something behind the screen which is not controlled by the programmer, and does inefficient things where there is a better, straight-forward and faster solution (i.e. explicitly write a loop statement, where you want to loop). ♪♫ Alex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
