Path: utzoo!yunexus!geac!syntron!jtsv16!uunet!lll-winken!lll-tis!ames!mailrus!tut.cis.ohio-state.edu!bloom-beacon!think!barmar
From: barmar@think.COM (Barry Margolin)
Newsgroups: comp.lang.lisp
Subject: Re: Protection of core lisp fns (was: Re: Question about eval)
Message-ID: <29663@think.UUCP>
Date: 24 Oct 88 16:19:53 GMT
Article-I.D.: think.29663
References: <13733@iuvax.cs.indiana.edu> <20700006@iuvax> <29266@think.UUCP> <589@dcl-csvax.comp.lancs.ac.uk>
Sender: news@think.UUCP
Reply-To: barmar@kulla.think.com.UUCP (Barry Margolin)
Organization: Thinking Machines Corporation, Cambridge, MA
Lines: 36

In article <589@dcl-csvax.comp.lancs.ac.uk> simon@comp.lancs.ac.uk (Simon Brooke) writes:
> And if we aren't allowed to redefine the way the top-level read - eval
>- print loop works, then the language certainly isn't as expressive: there is
>a large category of things it can't express.

You are assuming that we are actually removing a capability that
currently exists.  Nowhere in CLtL does it say what the effect of
redefining a standard function is (it DOES specifically disallow
redefining standard special forms).  Nor does it say that the
top-level Read-Eval-Print loop actually calls EVAL.  It might call
SYSTEM::EVAL-INTERNAL in some implementations, for instance, so a
redefinition of EVAL would have no effect on the top-level evaluation,
only on explicit calls to EVAL by user code.

Additionally, an implementation might choose to inline code some
standard functions.  For example, most implementations open code CAR
and CDR, so redefining these functions wouldn't affect anything
compiled before the redefinition.  And if it compiled calls to EVAL
inline (presumably into a sequence of calls to internal functions, not
copying the entire evaluator into each caller) then redefining EVAL
would have little effect.

Rather than try to list precisely which functions the user should be
allowed to redefine, we chose to specify that all standard functions
are sacred.

This doesn't mean that an implementation must prevent you from
redefining standard functions.  It just means that a program that does
so is not portable.  This is just making the status quo explicit in
the standard, since the behavior is currently inconsistent across
implementations.

Barry Margolin
Thinking Machines Corp.

barmar@think.com
{uunet,harvard}!think!barmar