This is the mail archive of the guile@cygnus.com mailing list for the guile project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
On Sat, 31 Oct 1998, Ian Bicking wrote: > I'd like to see *one* dictionary-like structure that is good enough to > replace all of these. It should be fast and robust. my hash tables are fast, but not 100% robust: the table breaks if the user accidentally (purposefully ?) mutates one of the keys, e.g. (define foo '(1 2)) (dictionary-add! my-dictionary foo "biz") (set-car! foo "jeepers!") (dictionary-lookup my-dictionary foo) #f ;; i.e., the dictionary thinks it isn't there > So it should print all pretty and be printed in a non-ambiguous manner > so that it can be reread from that printing, for instance. my hash tables are extended Scheme types, i.e. basic Scheme type: numbers, booleans, characters, the null list, etc. extended Scheme type: all basic Scheme types, any pair or vector of extended Scheme types they look like this (#(hashtab 3 #t #t) . #(((459024808 "biz" . "bizeroni") (-157169068 "pep" . "peperoni")) () () ((305423011 "froggy" . "froggieroni")))) and can be (read from)/(written to) a file using "read"/"write" > It should support accessing it anyway you choose (by key, by value, by > key-value pair, by mapping, by for-each, etc). Dictionaries are > important enough to be done completely. I would prefer to hide the keys' hash values from the user. I plan to have, e.g. dictionary->keys dictionary->values dictionary->pairs but not dictionary->entries where an "entry" would look like (hash-value (key . value)) > > > Transparent Code: Well, write as much of it in Scheme as possible. > > > If, for performance reasons, it isn't written in Scheme consider > > > providing a reference implentation which does the same thing as the C > > > (just slower). > > > > I've found that Guile C extensions are pretty readable (relative to > > Perl/Python extensions, Tcl? I have no idea) > > The C extensions aren't going to be as readable as Scheme (usually). > Relatively, they might be readable, but I know I can't get excited > about the idea of figuring out C code and how it relates to the Scheme > environment. I'd rather just stay in Scheme. any C extension providing procedures to operate on extended Scheme types (my extension meets this description) could be entirely implemented in Scheme (with modest to not-so-modest performance penalties). The best approach may be to keep the compute intensive operations (e.g., dictionary-add!, or the internal resize procedure) in C and write the rest in Scheme. Jay jglascoe@jay.giss.nasa.gov