> As first approximation to handling scope you would have stack of > hashtables.
> Key is irrelevant to the problem, but typically it is String. String is not much information. Identifier would be better. I guess the scope stores (idenifier, value) pairs where the value type contains all the information connected to the identifier. So what actually speaks against a "stack" of hashtables? By "stack" I would mean a datastructure Scopes(Identifier, Value) that allows search: (%, Identifier) -> Union(Value, "failed") and search: (%, Identifier, Integer) -> Union(Value, "failed") to search in scopes below the current scope at n levels deeper (n given by the third argument). One could implement this as List XHashTable(Identifier, Value) where each new scope (hashtable) goes to the front of the list and contains only (identifier, value) pairs that are new in this scope and that might shadow identifier in an outer scope. Doesn't that make working with scopes much easier? search(x: %, id: Identifier, n: Integer): Union(Value, "failed") == search(per rest(rep x, n), id) But I guess there is tons of literature in the compiler community describing efficient datastructures for handling scopes. Ralf -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group. To unsubscribe from this group and stop receiving emails from it, send an email to fricas-devel+unsubscr...@googlegroups.com. To post to this group, send email to fricas-devel@googlegroups.com. Visit this group at https://groups.google.com/group/fricas-devel. For more options, visit https://groups.google.com/d/optout.
