Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!samsung!uunet!zephyr.ens.tek.com!tekcrl!tekchips!kend
From: kend@tekchips.LABS.TEK.COM (Ken Dickey)
Newsgroups: comp.lang.lisp
Subject: Re: LISP compiler?
Message-ID: <5032@tekcrl.LABS.TEK.COM>
Date: 9 Nov 89 21:13:29 GMT
References: <2606@bingvaxu.cc.binghamton.edu> <1325@skye.ed.ac.uk> <20585@mimsy.umd.edu> <5057@internal.Apple.COM> <4327@hplabsz.HPL.HP.COM>
Sender: ftp@tekcrl.LABS.TEK.COM
Reply-To: kend@tekchips.LABS.TEK.COM (Ken Dickey)
Distribution: usa
Organization: Tektronix, Inc., Beaverton,  OR.
Lines: 24

In article <4327@hplabsz.HPL.HP.COM> mayer@hplabs.hp.com (Niels Mayer) writes:
>I think the biggest problem with lisp is that it lets you be sloppy with
>memory management... most big lisp systems I've worked with generate
>garbage in low-level modules that must eventually be garbage collected.  If
>you try to optimize this by rewriting your modules to be "cons-free", the
>code becomes so spaghetti-like that you might as well be writing it in C.
>How can compilation solve the problem of lisp's memory inefficiencies?
>

I think that you are overgeneralizing your experience.  I have 2 suggestions:

  (1) Change your coding style so that your declarations are compiled
statically [i.e. write your code in a *clean* style which does not cons].
[I don't buy your spagetti argument].

  (2) Get a runtime system which is written not to cons.  Demanding better
runtime libraries from your suppliers is a worthwhile occupation.


By the way, what do you mean by Lisp (MacLisp, InterLisp, Scheme,
CommonLisp, Franz...)?


-Ken Dickey			kend@mrloog.WT.TEK.COM