merits of Lisp vs Python

[Rob Thorpe]

Anders J. Munch wrote:
> Rob Thorpe wrote:
> > Anders J. Munch wrote:
> >> Let u(t) be the actual memory used by the program at time t.
> >> Let r(t) be the size of reachable memory at time t.
> >>
> >> Require that u(t) is a member of O(t -> max{t'<=t: r(t')})
> >>
> >> There. That wasn't so hard, was it?
> >
> > That's quite a clever definition actually.
> > But, let's say I have a lisp machine.  It has an unusual architecture,
> > it's made entirely of SRAM cells of ~9bits.  Sometimes these cells are
> > used as storage, sometimes their contents represent logic circuits and
> > the routing between them is configured to form them into a processor.
> > Please tell me what reachable memory is ;).  (The above processor is
> > not science fiction, it could easily be done with FPGAs)
>
> Reachable memory is the set of interpreter objects (conses, closures, scopes,
> atoms and what have you) reachable from from some appropriately defined root
> set.  It can be unambiguously defined with respect to a virtual machine, with no
> regard to how actual implementations represent these things.

Yes.

> For actual memory use, a simple byte count would do fine.  If code and data are
> intermingled, just use the combined size of both of them.

Well, in my example the code, the data and the processor are
intermingled.  Still you could do it this way.  But, what would happen
for example if on a normal machine someone wrote a program that
generated lots of functions that it never used, would it have to be
detected by the GC.  This is hard to do.  The solution is probably to
define the root set only in terms of data.

> If you're worried about comparing incompatible units, don't be: apples and
> oranges compare just fine under big-Oh.

Yes. Thank you for comprehensively out-arguing me.

I'll give one last reason why it may not be a good thing to define:
reference counting.  Some people want to use refcounts, and believe
that under certain circumstances they provide better performance than
GC.  I don't know if they're right, I suspect they are for some limited
circumstances.  A normal ref-count system can't be gauranteed to have
no memory holes introduced by loops in the data.  But, if the
programmer causes no loops to come into being then he/she is safe.  An
implementation that used refcounting might not be of much general use,
but for specific purposes, embedded programming for example, it might
be useful.