Subject: Re: looking for a language with any of the following 4 charachteristics (all 4 would be nice). From: Erik Naggum <erik@naggum.net> Date: Sat, 16 Feb 2002 20:35:15 GMT Newsgroups: comp.lang.lisp Message-ID: <3222880518268721@naggum.net> * Erann Gat | What I'm saying is that when it comes to associative maps -- an extremely | important abstraction (arguably the most important in all of computer | science, but that's another discussion) -- this philosophy of deferring | decisions breaks down, at least within the bounds of the current standard. Not so. If you are at all uncertain about how to deal with these things, you either write macros or functions to hide the implementation technique you (need to) use, and those macros would be named after the particular association mapping needed, not afte the functionality alone. | I can't say "I want an associative map, and I want to defer the decision | of whether the underlying implementation will be an alist, a plist, a | hash-table, a binary-tree, a trie, or something else." Of course you can. Why have you turned into such a mindless troll? Lest you have forgotten because of your C++ exposure of late, over here in Common Lisp land, we shape the language to suit our needs, we do not only used the lowest-level built-in functionality without modification or reflection upon our needs. > Also, alists and plists don't suffer from rehash problems upon garbage > collection. | Now this is something I'm not familiar with. Could you elaborate? Is it not obvious? If an eq or eql hashtable hashes on the machine address of the object, which is a pretty obvious thing to do, those machine addresses will change if garbage collection moves live objects, such as many GC algorithms do. Therefore, such a hashtable will need to survive those object movements, somehow. This may not be a trivial task. For instance, symbols, which are very useful in eq hashtables, have their own hashing code as part of the symbol structure in Allegro CL to avoid this high cost. Something similar to this can obviously not be done for a lot of other useful hashing keys. /// -- In a fight against something, the fight has value, victory has none. In a fight for something, the fight is a loss, victory merely relief.