On Thu, Jun 18, 2009 at 4:03 PM, Matthew Flatt<mfl...@cs.utah.edu> wrote: >> >> I see. I have contracts set up to accept only symbols and keywords >> whose names are ASCII strings; I was planning to use a weak, eq?-based >> hash of their names to shortcut the test. Apparently, though, I >> cannot get eq?-unique names for symbols and strings. If I hash the >> symbols and keywords themselves, I believe the weak table can never >> reclaim the space (since interned symbols and keywords are forgeable); > > No --- symbols and keywords are GCed, so a weak hash table would work. > > (And weakness in hash tables isn't about whether you could synthesize > the key. We have `equal?'-based hash tables with weak keys, after all.)
I see. I tried to demonstrate this one way or another to myself with a weak box containing a symbol and a call to collect-garbage, and the box never "emptied". Perhaps that experiment was not conclusive; maybe collect-garbage doesn't guarantee emptying of all weak boxes, or I had a reference to the symbol lying around somewhere I didn't know about. >> However, while I'm musing out loud... would it be possible to have >> symbol->bytes and keyword->bytes that produce the UTF-8 representation >> (presumably with guarantees of uniqueness, immutability, and proper >> UTF-8 encoding)? > > Do you mean that `symbol->bytes' would avoid allocation, which is > possible because the symbol is UTF-8 encoded? > > If so, there's another part of the representation story that I left out > last time. A symbol's content is "inlined" into the allocated symbol > record, while a string or a byte string is a record containing a > pointer to the string's characters. This difference has to do with C > interoperability and a GC-based prohibition on pointers into the > interior of an allocated object. So, there are many ways in which the > current representations don't yield a cheap `symbol->bytes' operation. I figured there might be something like that going on. Not a major issue, I will get along without this. --Carl _________________________________________________ For list-related administrative tasks: http://list.cs.brown.edu/mailman/listinfo/plt-dev
