guile-user
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Marko Rauhamaa
Subject: Re: cannot compile: srfi-10 define-reader-ctor 'hash '#,(
Date: Thu, 14 Aug 2014 00:33:04 +0300
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux)

Jan Nieuwenhuizen <address@hidden>:

> Marko Rauhamaa writes:
>
>>>    {"key0": value, "key1": value}
>>
>> You mean, like,
>>
>>    (hash-map->list cons mytable)
>
> No; when fed to `read', that produces a list, right?

It produces a mapping in the elegant, classical lisp format: the assoc
list.

A hash table is just an implementation of that mapping. There's barely a
better way to externally represent the mapping than an assoc list.

I can use a hash table, send an assoc list to communicate the mapping to
a peer, who can then decide to store the mapping in an assoc list,
balanced tree, hash table, object database or any other suitable
internal data structure. Forcing the recipient to read in a hash table
would be pointless and, frankly, obnoxious.

> I mean an standardized, ascii/utf-8 non-opaque (#<hash table xyz>)
> representation of hash tables, something like
>
>     #,(hash (key0 value0) .. (keyn valuen))
>
> that upon `read', produces a hash table.

I know what you mean. I just can't imagine much of a practical need for
it.

If you want to use pretty-printing to dump the internal data structures
so you can recreate them later, that wouldn't work anyway. Consider:

   (define b (cons 'x 'x))
   (define a (cons b b))
   (pretty-print a)
   => ((x . x) x . x)
   (define c '((x . x) x . x))
   (eq? (car a) (cdr a))
   => #t
   (eq? (car c) (cdr c))
   => #f


Marko



reply via email to

[Prev in Thread] Current Thread [Next in Thread]