From ... From: Erik Naggum Subject: Re: Lisp is *SLOW* Date: 1997/07/22 Message-ID: <3078520173470566@naggum.no>#1/1 X-Deja-AN: 261748485 References: <5puscn$e0h$1@cdn-news.telecom.com.au> <33CE62F4.7C7B@capital.net> <33D001A3.4F70@capital.net> <5r0l5t$ecf$1@darla.visi.com> mail-copies-to: never Organization: Naggum Software; +47 8800 8879; http://www.naggum.no Newsgroups: comp.lang.lisp,comp.programming,comp.lang.c++ * Marco Antoniotti | If we want, we could discuss at length why some of the design choices | of "destructive" operations in Common Lisp sometime have a | non-intuitive behavior. do they? the question is one of which value one looks at, I think. `sort' on a list returns a sorted list, but the cons cells that used to be that list have been reused. if we look at the return value of `sort', we get the sorted list. if we look at a random cons cell that has been reused in some unspecified way, who's to tell? like `nreverse' in one implementation swaps the `car' of cons cells, and in another the `cdr', we cannot know what a cons cell that has been destructively modified would contain, unless the operation is specified by the specification of the language, and it isn't for `sort' or `nreverse'. or, another way: after (sort ), is _history_. #\Erik -- there was some junk mail in my mailbox. somebody wanted to sell me some useless gizmo, and kindly supplied an ASCII drawing of it. "actual size", the caption read. I selected smaller and smaller fonts until it vanished.