From: Nikodemus S. <nik...@ra...> - 2009-04-29 10:48:48
|
2009/4/29 Leslie P. Polzer <sk...@vi...>: >> 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 the application. >> * Does this patch allow setting of function documentation >> for closures > > Yes. 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 with %COMPILER-DEFFOO. 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. Cheers, -- Nikodemus |