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] |
Jay Glascoe writes: > > 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 I can't see how you'd get around that, without having some sort of mechanism to tell when foo is modified or to make foo unmodifiable. Putting a trace on foo is too hard and not worth it by a long shot. Making it unmodifyable might be kind of nice... but either way it's not really worth the effort. Users just shouldn't do that sort of thing. I guess this makes it not completely robust, but only depending on how you define what you are trying to do. > > 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")))) Is there a mechanism to make a new type, or are all extended types going to be these sorts of ad-hoc pasting together of information? Judging from the hash-table representation, the only way to tell a hash-table from some other vector is by usage. That means there isn't any pretty printing for hash-tables, all functions on hash tables must be "hash-*", and other unattractive things. It seems like this would be an argument against calling Scheme/Guile a VHLL. When a vector is no longer a vector (i.e., has significantly more internal structure) it shouldn't be a vector. It deserves its own type. ... > I would prefer to hide the keys' hash values from the user. I plan to > have, e.g. > > dictionary->keys > dictionary->values > dictionary->pairs Yes, hash values aren't something users need to look at. If it really is a "dictionary" and not a hash-table, then the hash values should be completely hidden (as an implementation detail). I think dictionary-map, dictionary-foreach, dictionary-map-association, etc. are also good function to have. Just about everything that can be done to lists can be done to a hash table (though it can be done in two ways, i.e., by value or by association/pair). I don't think having "keys" is too important. The key shouldn't be important except with respect to the value it is associated with. And even if someone does want just the keys, they can get the pairs and get the key from that. To a degree, I think it's analogous to someone wanting to get all the indexes for a vector. This is used, vector-length (which implies all the other indexes) gives this. The only place where I can see this getting used is when you iterate over the vector -- but dictionary-map et. al. should suffice for these needs. Is there anyplace else where vector-length is used that's not to get the size of the vector (which is another concept)? ... > 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. I see the reasons for the Scheme source being for debugging (where speed is usually not too important) and pedagogy (where the source is around to be read, not necessarily run). In these cases, it's not so important to worry about performance, but more about the ability to transparently have visible Scheme source but a C implementation (with the possibility of using the Scheme source as the implementation). <-------------------------------------------------------------------> < Ian Bicking | bickiia@earlham.edu > < drawer #419 Earlham College | http://www.cs.earlham.edu/~bickiia > < Richmond, IN 47374 | (765) 973-2824 > <------------------------------------------------------------------->