Date: Mon, 21 Dec 2009 00:37:10 +0000 From: [email protected] Of course the response to this is that the obarray isn't intended to be used in this manner. It is not guaranteed to retain symbols and that it was simply an implementation detail that it happened to retain them. And user code should not assume that calling intern on a symbol will cause it to appear in the obarray.
I argue the same is true of hash tables. User code should not assume that inserting a key/value pair in the table will cause the key to appear in the key-list. Your last sentence is not the documented intent, and would severely restrict the applicability of the hash table abstraction. There are cases in which that assumption is valid, and there are cases in which that assumption is not valid. In the case of the obarray (which is not expressible using the runtime's hash table abstraction, of course, because the hash table abstraction does not support key-strong, datum-weak hash tables, which is what the obarray is), the assumption is not valid. _______________________________________________ MIT-Scheme-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/mit-scheme-devel
