Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!elroy.jpl.nasa.gov!decwrl!parc!cutting
From: cutting@parc.xerox.com (Doug Cutting)
Newsgroups: comp.lang.lisp
Subject: Re: Is this the end of the lisp wave?
Message-ID: <CUTTING.91Jan23141807@skye.parc.xerox.com>
Date: 23 Jan 91 20:18:07 GMT
References: <NETMAILR11011708110SEB1525@MVS.DRAPER.COM>
	<17374@csli.Stanford.EDU>
Sender: news@parc.xerox.com
Organization: Xerox PARC, Palo Alto, CA
Lines: 40
In-Reply-To: ceb@csli.Stanford.EDU's message of 23 Jan 91 06:38:55 GMT

In article <NETMAILR11011708110SEB1525@MVS.DRAPER.COM> SEB1525@mvs.draper.com writes:

   The Big Win is:  Storage management in Lisp is a non-issue.

No, Garbage collectors don't make storage management a non-issue, they
just make it less of an issue (unless you don't care about performance).

In article <17374@csli.Stanford.EDU> ceb@csli.Stanford.EDU (Charles Buckley) writes:

   However, I'd still like to do my own storage management in Lisp
   when my algorithm makes that possible and expedient.  It's simply
   not provided for in CL. 

I'm not sure what you're talking about.  One can easily do one's own
storage management in CL.  It's not considered exemplary coding style,
but when used judiciously can provide substantial acceleration (e.g.
for long-lived objects under a generation scavenging GC).

(defvar *cons-cells* () "Free list of CONS cells linked by CDR")

(defun make-cell (car cdr)
  (let ((cell *cons-cells*))
    (cond
      (cell
       (setq *cons-cells* (cdr *cons-cells*))
       (setf (car cell) car)
       (setf (cdr cell) cdr)
       cell)
      (t (cons car cdr)))))

(defun reclaim-cell (cell)
  (setf (car cell) nil)
  (setf (cdr cell) *cons-cells*)
  (setq *cons-cells* cell)
  nil)

This could be done with generic functions ALLOCATE and FREE, but this
is not usually needed and adversely affects performance.

	Doug