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.