2009/4/29 Leslie P. Polzer <sky@...>:
>> How would this compare with a weak hash table keyed on
>> function objects?
> I don't know. Intuitively I'd guess that a weak hash table in
> the infodb might yield better results in terms of memory.
At any rate, as long as weak hash tables have non-linear GC
characteristics I don't think we should be adding any more of them to
the build -- especially not ones that grow linearly with the size of
>> * Does this patch allow setting of function documentation
>> for closures
I don't think it does -- not in the sense I believe Christophe means:
(defun foo (x) (lambda () x))
(let ((f1 (foo 1))
(f2 (foo 2)))
(setf (documentation f1 t) "FOO 1"
(documentation f2 t) "FOO 2")
(equal (documentation f1 t)
(documentation f2 t)))
will return T, as the closures share the same simple-fun. Similarly
for funcallable instances: the only available slot is in the final
underlying simple-fun. I don't consider this a problem. Storing
function names shares this issue, and I believe both are best fixed at
the same time -- which does not have to be now. It could be, but it
doesn't have to.
All in all, I like this patch, except for the %DEFINE-PRIMITIVE-OBJECT
change, which would be a departure from the convention that we
implement load-time bits of DEFFOO with %DEFFOO, and compile-time bits
If function size increase is a concern, the slot could be merged with
XREFS into a single SIMPLE-FUN-INFO slot, which would hold one of (1)
NIL when neither documentation nor xref data is present (2) a string
when only documentation is present (3) a simple vector when only xrefs
are present(3) a CONS holding both when both are present.