Arc Forumnew | comments | leaders | submitlogin
Arc implementation: why to use namespace to store arc's vars
3 points by zhtw 5290 days ago | 6 comments
Ac.scm contains a lot of namespace-set-variable-value!/namespace-variable-value combined with ac-global-name. Is there a specific reason for not using hash-tables to store arc's variables?


3 points by CatDancer 5289 days ago | link

As Arc compiles to MzScheme, Arc global variables become MzScheme global variables, and MzScheme stores global variables in a namespace.

-----

3 points by zhtw 5289 days ago | link

Yes, I understand that. And that's why I asked the question. Conanite said that it might be for performance reason. Do you think it is?

-----

1 point by conanite 5289 days ago | link

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.

-----

1 point by zhtw 5289 days ago | link

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.

-----

3 points by conanite 5288 days ago | link

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 ...

-----

1 point by zhtw 5288 days ago | link

Interesting. I'm sure there is no need to do a lookup for symbols in local scope. But we're talking about globals.

What about this:

(eval (coerce "car" 'sym))

-----