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

[Marko Rauhamaa]

Taylan Ulrich Bayirli/Kammer <address@hidden>:

> To be fair, when your read syntax makes dictionaries explicit, you get
> an additional bit of "safety" [...]
> (I've been bitten by this [...]
>
> On the other hand, if you just implement full validation [...]

Yes, validation is a much more generic issue that can be used for all
kinds of bounds-checks and interrelationships.

On the other hand, I wouldn't put too much emphasis into validation (as
in, none at all). For example, I have customized emacs with all kinds of
lisp data structures. None of those data structures are validated by the
respective emacs modules; they are simply obeyed. Typos create errors
and misbehaviors -- so I must fix them, simple as that.

> All in all, having to use alists for hash tables can be an annoyance
> when you don't use eager input validation; it forces you to use extra
> alist->hash-table and hash-table->alist calls where you could
> otherwise just read and write an object if all it contains is lists,
> vectors, and hash tables, and it can cause some bugs to remain hidden
> for longer.

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.


Marko


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. In
guile, I have to use

   (lambda (sym1 sym2)
     (string< (symbol->string sym1)
              (symbol->string sym2)))

instead of something like:

   (lambda (sym1 sym2)
     (< (id sym1)
        (id sym2)))

or even:

   below?

(in analogy with eq?).


Marko