Marko Rauhamaa <ma...@pacujo.net> writes: > A hash table is an optimized, internal lookup object. It is not a > meaningful representation format. An AVL tree and a hash table should > have identical external representations in almost all cases. Thus, my > implementation would have to make the translation on input anyway.
If your program cares about specialized data structures like that then yes, but often one just wants a generic "dictionary" type with O(1) lookup, whatever the details. Though when I think of it, often I would be fine with O(n) too and could use alists in my code to begin with. As I said, I just think it's a minor annoyance, not having a "go to" dictionary type that covers 90% of use cases and can be serialized as well. Typos in keys is a bigger problem; having the compiler tell me I mistyped the name of an accessor is much better than having an exception thrown somewhere, sometime, and having to debug a little until I find out it was just a typo! Hence input-time validation is generally the way to go IMO. (Or maybe the relative difficulty of debugging Objective-C, the language I have to use at work, is making me biased.) > PS Speaking of AVL trees, my AVL tree implementation is bitten by the > apparent lack of a numeric object identifier in guile. Python has the > id() function that can be used to sort interned objects effectively. There is (pointer-address (object-pointer <obj>)) if that helps. (Nonstandard Scheme of course.) Taylan
