I don't know scheme, but it might be for performance. The earliest iterations of rainbow used hashes for global symbols but profiling showed that was a bad idea. Now, each symbol object stores its own value, so there is no lookup, and stuff runs faster.
I don't understand how there cannot be lookup in both cases. The only difference I can guess is that in case of hashes you might have used strings as keys and when using symbols the lookup is done only by pointers. But that's the same in scheme if use use symbols as keys in hash table.
zhtw, your profile says you're building a lisp compiler, so I'm taking the liberty of exposing the innards of rainbow a little, it might be helpful:
public class Symbol {
String name;
ArcObject value;
// ... etc
}
Pieces of arc code contain direct references to these Symbol objects. For example, (car x) is implemented by something like this:
class Invoke_Sym_Lex {
Symbol fn; // points to the "car" symbol
LexicalSymbol arg;
public void invoke(...) {
fn.value.invoke(arg);
}
}
there is no lookup. The symbol is baked into the code. Lexically-bound symbols are more complicated, but they don't use hashes for lookup either.
As far as I can tell, this approach will support namespaces without any performance penalty, except perhaps at read/compile-time. Assuming arc gets namespaces one day ...
