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

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.


> >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

♪♫ Alex
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Reply via email to