Re: Getting rid of compiled closures?

[Dirk Herrmann]

On 5 Dec 2000, Mikael Djurfeldt wrote:

> Dirk Herrmann <address@hidden> writes:
> 
> > However, for these gprocs it is not actually necessary to use a compiled
> > closure.  All information that is needed for their representation would
> > fit into a double cell.  The compiled closure implementation comes from
> > the time before there was the double cell possibility.  Now, they could
> > either be implemented using an applicable smob, or a tc7 code of their
> > own.
> 
> I think we should do this.  BTW, in a previous mail to Keisuke I
> explained how the applicable smob implementation can be optimized wrt
> dispatch.  Maybe we should have a look at my suggestion before
> implementing your suggested change.  Tell me if I should forward my
> suggestion.

Yes, that would be nice.

> > If that was done, the concept of compiled closures could be removed from
> > guile.
> 
> While I think we should go ahead wrt gprocs as applicable smobs we
> should probably think once or twice before removing compiled closures.
> 
> Currently, compiled closures is the only way to easily construct
> tail-recursive procedures with attached data from the C level.  I
> think I've used this in some application.

I have to admit that I don't understand that at all.  Why are compiled
closures safer with respect to tail recursiveness than applicable
smobs?  I couldn't find any useful information about that in any of the
docs, and I still don't understand the evaluator :-(  To me it would be
very helpful to understand the principles one has to follow in order to be
able to grant tail recursiveness with the current evaluator.

Best regards,
Dirk Herrmann