[Top][All Lists]

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

Re: Getting rid of compiled closures?

From: Dirk Herrmann
Subject: Re: Getting rid of compiled closures?
Date: Wed, 6 Dec 2000 10:16:22 +0100 (MET)

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

reply via email to

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