Re: cannot compile: srfi-10 define-reader-ctor 'hash '#,(

[Taylan Ulrich Bayirli/Kammer]

Marko Rauhamaa <address@hidden> 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