guile-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Optimization of applicable smobs


From: Dirk Herrmann
Subject: Re: Optimization of applicable smobs
Date: Thu, 7 Dec 2000 16:43:22 +0100 (MET)

On 7 Dec 2000, Mikael Djurfeldt wrote:

> > Regarding tail-recursiveness, what about adding a new flag that
> > indicates that the return value of a smob application must be called
> > once again tail-recursively?
> 
> Yeah, we need something like this.  Note that we need to return the
> arguments as well...  Also, we should coordinate this change with
> Gary's recent implementation of multiple values.

I wonder if it was possible to solve this via a 'tail-call' object, which
some functions may return instead of a 'normal' return value?  Callers of
those functions would have to be aware of the fact, that a tail-call
object may be returned.  They could then either immediately execute the
tail call, or pass it on to their own caller (who then should also be
aware of the possibility that a tail call object is returned), or do
something else with it, like using if for debugging purposes or whatever
(although there is probably not much sensible that can otherwise be done
with a tail-call object).

If this could work, then we could also realize byte compiled functions as
applicable smobs.  The applicable smob simply returns a tail-call object,
which represents the call to the bytecode interpreter.  If, for example,
this tail-call is received within the evaluator at at tail position, the
evaluator can simply return the tail-call object and leave the execution
of the tail-call object to the next lower stack frame.  Thus, the bytecode
interpreter will not have to be started on top of the already running
evaluator stack frame.  This means, different evaluators could easily
replace each other on the stack, given they are called in tail positions.

Am I really beginning to understand all this evaluator stuff, or am I just
talking rubbish ?  :-)

Best regards,
Dirk Herrmann




reply via email to

[Prev in Thread] Current Thread [Next in Thread]