Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 8/23/84; site ucbcad.UUCP
Path: utzoo!watmath!clyde!bonnie!akgua!mcnc!decvax!ucbvax!ucbcad!faustus
From: faustus@ucbcad.UUCP (Wayne A. Christopher)
Newsgroups: net.lang
Subject: Re: Re: Lisp Machines
Message-ID: <3@ucbcad.UUCP>
Date: Fri, 24-May-85 03:17:00 EDT
Article-I.D.: ucbcad.3
Posted: Fri May 24 03:17:00 1985
Date-Received: Sun, 26-May-85 00:42:06 EDT
References: <922@noscvax.UUCP> <5604@utzoo.UUCP> <3345@utah-cs.UUCP> <4314@mit-eddie.UUCP> <3346@utah-cs.UUCP>
Organization: UC Berkeley CAD Group, Berkeley, CA
Lines: 37

> I don't know why debugging compiled code is such a wonderful thing;
> object code (even on a LM) is not particularly readable.  With the
> interpreter you can see exactly what is being executed.

I think that dbx is a pretty useful debugger, and C is compiled. The same
sort of debugger cold be run easily for lisp. You have the advantage of
not having to worry about things working differently when you are compiled
from when you are interpreted, too.

> While runtime
> type checking does increase robustness, it's usually an incredible
> waste of resources; 99.99999% of type tests will return a result that
> is knowable in advance (the remaining .00001% are bug detections).

Really? Say you are doing a lot of high-precision numbers -- how do you
know whether you are adding fixnums, bignums, or flonums? You will often
have two pointers to something, and want to know whether they point to
the "same" thing. What you do depends on whether they point to ints,
atoms, or whatever.

> In general, I tend to object to doing complex operations (like typechecking)
> in hardware - it's just too inflexible.  Does anybody really believe
> that the primitive types in Zetalisp are worth wiring into the machine
> (or even the microcode)?

I don't know about Zetalisp, but considering the sorts of worries you
have when designing a prolog machine, it certainly is worth the trouble.

> I agree, but a GC coprocessor is really all you need.  Actually, it
> would be better just to have a vanilla multiprocessor, and run GC
> tasks concurrently with computation tasks, but that's still in research!

I think the point of having special hardward for this is so that you
can have extra gc bits along, instead of having to use structs instead
of just plain pointers...

	Wayne