Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!apple!usc!samsung!spool.mu.edu!uunet!mcsun!ukc!edcastle!aiai!jeff
From: jeff@aiai.ed.ac.uk (Jeff Dalton)
Newsgroups: comp.lang.lisp
Subject: Re: Memory Management in Lisp?
Message-ID: <4234@skye.ed.ac.uk>
Date: 25 Feb 91 15:12:05 GMT
References: <1991Feb15.191259.20090@aero.org> <1991Feb15.223520.17267@Think.COM> <1991Feb18.191549.7575@aero.org> <1991Feb19.030719.1137@Think.COM> <PCG.91Feb23162955@odin.cs.aber.ac.uk>
Reply-To: jeff@aiai.UUCP (Jeff Dalton)
Organization: AIAI, University of Edinburgh, Scotland
Lines: 66

In article <PCG.91Feb23162955@odin.cs.aber.ac.uk> pcg@cs.aber.ac.uk (Piercarlo Grandi) writes:

>This is a very untraditional concern. It used to be fairly true, as one
>quote puts it, that "Lisp programmers know the value of everything but
>the cost of nothing" :-).

That must be why they never bothered to write compilers :-).

>barmar> Traditionally, one of the most important differences between
>barmar> Lisp and most other languages has been the fact that memory
>barmar> management is automatic.
>
>Unfortunately this has traditionally encouraged sloppiness.  For example
>many functions, where even without this simple technique garbage
>generation should be zero, are sloppily coded. Part of it may be desire
>to aboit using 'set' or 'rplac' variants, part of it is just
    avoid ?
>carelessness.

Well, of course many functions are sloppily coded.  This is a problem
in every programming language.  But I don't count a lack of attention
to object lifetimes as part of the sloppiness except in certain cases.
More often automatic storage management makes it easier to write code
that is clearer and in a sense more abstract.

>This is simply because Lisp programmers have always been offered,
>because they were doing "research", the largest machines around and
>resource consumption has never been a problem, until they started having
>to do delivery. 

I think this is true to a large extent, although resource consumption
_has_ often been recognized as a problem.

>                 But unfortunately just like the nerds in Unixland don't
>know anything about locality of reference, the hackers in Lispland don't
>even think about garbage generation rates. I am sure that you, an old
>Multics fan, can weep with me for hours about both attitudes.

A number of Lisp hackers _did_ think about garbage generation rates
when it was appropriate to do so.

>barmar> Even EVAL isn't as fundamental to Lisp as I once thought, since
>barmar> Scheme doesn't have it [ ... ]
>
>The entire Scheme report is really about defining the semantics of
>'eval'. 

I hope you're not supposing that Barmar didn't know this.

>It does not have a way to invoke recursively the 'eval', but
>that is probably best left as an implementation issue.

There are programs that can use it and they cannot be written in
portable Scheme.  There are good reasons for leaving EVAL out of
Scheme, but they are not so good that all Lisps should do the same.
I don't see how any of this makes it an implementation issue.

>Also, Scheme is not a Lisp -- it is an Algorithmic Language :-).

Single inheritiance thinking rides again.  [Common Lisp is a Lisp but
not supposedly an "Algorithmic language".  Scheme is an Algorithmic
language.  Since Algorithmic language is not a subcategory of Lisp,
and Lisp is not a subcategory of Algorithmic language (because of
such Lisps as Common Lisp), it must be that Scheme is not a Lisp.]

-- jd