Re: setf.scm

[Mikael Djurfeldt <mdj@nada.kth.se>]

Maciej Stachowiak <mstachow@MIT.EDU> writes:

> I've been trying to figure out how closures are laid out so I can make
> a guess as to whether this will be true. Right now it seems closures
> are a cons cell, the car of which is a cons cell of the code and the
> properties, and the cdr of which is the environment.

That is correct.

> I can see what you mean about the extra indirect references, but I'd
> need to see benchmarks to be convinced how much of a difference this
> makes. I am also curious if the decision to make the code more
> indirect rather the environment was random or based on performance
> analysis of the two possibilities.

I don't know how the decision was made, but I think we can count on it
that no performance analysis or benchmark has been done.

> > (I've actually been thinking about removing the procedure-property
> >  slot.  That would remove one level of indirection in the inner loop
> >  of the evaluator.)
> 
> Actually those could easily live in a separate weak hash table as
> accessing them hardly ever performance critical.

Exactly.  This would have the additional benefit of working for the
primitive procedures.  Have you seen the current O(N) implementation
of procedure properties for primitive procedures?  Very nice... :(

> Are there any procedure properties that need to have special
> semantics other than arity?

Arity shouldn't have special semantics apart from being read-only.
(That is, procedure-property and procedure-properties should behave as
 if arity was a "normal" property.)  Other properties used internally
in Guile are `name', recording the name of the first variable bound to
the procedure in the global environment, `inner-name' recording the
name bound to an inner definition, and, `trace' which is the trace
flag.

The trace flag is the only one which is performance critical.  It
should perhaps also be specially treated.

/mdj