From ... Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed00.sul.t-online.de!t-online.de!newsfeed.esat.net!nslave.kpnqwest.net!nloc.kpnqwest.net!nmaster.kpnqwest.net!nreader2.kpnqwest.net.POSTED!not-for-mail Newsgroups: comp.lang.lisp Subject: Re: data hygiene [Re: Why is Scheme not a Lisp?] References: <87u1rkl068.fsf@charter.net> <87wuwg1b05.fsf@photino.sid.rice.edu> <87ofhrc3ed.fsf@charter.net> <874rjj1ve1.fsf@photino.sid.rice.edu> <87it7yz2sf.fsf@photino.sid.rice.edu> <87d6y5heq2.fsf@becket.becket.net> <87elilwsnx.fsf@photino.sid.rice.edu> <87u1rfn07o.fsf@becket.becket.net> <87k7sbtzp5.fsf@photino.sid.rice.edu> <871yej1v0h.fsf@becket.becket.net> <87y9grsfa1.fsf@photino.sid.rice.edu> <87henf4hbk.fsf@becket.becket.net> <87sn6ybycz.fsf@asaka.latnet.lv> <877ko9ai6x.fsf@becket.becket.net> Mail-Copies-To: never From: Erik Naggum Message-ID: <3225483324695497@naggum.net> Organization: Naggum Software, Oslo, Norway Lines: 70 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 18 Mar 2002 23:35:13 GMT X-Complaints-To: newsmaster@KPNQwest.no X-Trace: nreader2.kpnqwest.net 1016494513 193.71.199.50 (Tue, 19 Mar 2002 00:35:13 MET) NNTP-Posting-Date: Tue, 19 Mar 2002 00:35:13 MET Xref: archiver1.google.com comp.lang.lisp:29475 * Thomas Bushnell, BSG > But I think it's generally thought by Lispers that it's a shame that > plists and alists have different structure, and if it were to be done > over again, plists would have the alist structure. So you can't > destructure a plist easily, but except when actually dealing with plists, > you are advised in Common Lisp to use alists instead, in general. * Janis Dzerins > How do you come up with this stuff? * Thomas Bushnell, BSG | Um, it's true. plists and alists have unfortunately different | representations, for historical reasons. And from this you conclude the "shame" part? And this "unfortunately" part is so prejudicial it hurts. | The alist representation is better (for one thing, it's just prettier, | but also, it allows for NIL properties). What on earth are you talking about? Neither properties named nil nor properties on the symbol nil are a problem: (get 'nil 'nil 42) => 42 (setf (get 'nil 'nil) t) => t (get 'nil 'nil 42) => t I think you should try to realize that you do not know these things and stop embarrassing yourself by posting more obviously clueless falsehood. | plists are stuck with the first way, however, because there is just way | too much code that knows how they work. Are you sure you are not confusing plist and alists? Are you confused by the fact that a nil in an alist is effectively ignored with any nil properties? (assoc nil '(nil (nil . 1) (2 . nil))) => (nil . 1) (rassoc nil '(nil (nil . 1) (2 . nil))) => (2) | But if you want to make your own assoc list, you always use the alist | representation and not the plist representation, with the exception of | what you store on actual symbols' plists. Really? Did you know that you can use destructuring-bind to pick up a bunch of values from a plist, but that you have no such handy tool with alists? (properties ) => (:root 'n :toot 'n :foo 47 :bar 11 :zot 'yeah) (destructuring-bind (&key foo bar zot &allow-other-keys) (properties ) (values foo bar zot)) => 47 => 11 => 'yeah I use this technique quite frequently to avoid having a whole bunch of empty slots in classes or structures. I trust that keyword handling in Common Lisp is implemented efficiently because it is such an integral part of the language. In a language that lacked such integral features, I would be much less likely to believe that some incidental library was sufficiently well implemented that I could use it. /// -- 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.