Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!mit-eddie!bloom-beacon!dont-send-mail-to-path-lines
From: gjc@mitech.COM
Newsgroups: comp.lang.scheme
Subject: Maclisp vs. CL & Scheme (r^4).
Message-ID: <9103011804.AA29248@schizo>
Date: 1 Mar 91 13:21:27 GMT
Sender: daemon@athena.mit.edu (Mr Background)
Reply-To: gjc@mitech.com
Organization: The Internet
Lines: 24

Funny thing about EVAL in Maclisp:

Even if Maclisp did not have EVAL, it would be possible, nay, I know
from experience that it *was* possible, to write an EVAL in Maclisp.
With the proper calls from DDT you could even patch your running
copy of "TS LISP" so that your new eval took the place of the EVAL
built-in written in PDP-10 assembler.

You could write MACLISP EVAL in MACLISP using only documented primitives.
You could write MACLIPS READ in MACLISP using only documented primitives.
You could write MACLISP PRINT in MACLISP using only documented primitives.

In COMMON-LISP it is *NOT* *POSSIBLE* to write PRINT using only
functions provided in COMMON-LISP. It may be possible to write READ and EVAL.
(Any comments?)

What about the new Scheme standard. Even if it does not have EVAL,
is it possible to write EVAL? Is it possible to write READ and PRINT?

-gjc

p.s. It is not possible to write COMMON-LISP READ in COMMON-LISP,
because of some poor definition of the behavior of "#," at least.
And that is also something that gives trouble to attempts at EVAL.