Are there any LISP implementations, especially of Common LISP,
which get 5 instead of 1 as the result of the following run?
>>> (defun eval (x) 1)
eval
>>> 5
1
Does this change to eval ever change what load does?
Does (setf (symbol-function 'eval) #'(lambda (x) 1))
do exactly the same thing as (defun eval (x) 1) in all
Common Lisp implementations?
... Dan
In article <·····@iuvax.cs.indiana.edu> ······@iuvax.cs.indiana.edu (Dan Friedman) writes:
> Are there any LISP implementations, especially of Common LISP,
> which get 5 instead of 1 as the result of the following run?
>
> >>> (defun eval (x) 1)
> eval
>
> >>> 5
> 1
Yep - I just tried it in Allegro common lisp (from Franz Inc) on my
sun-3 and got just that.
Looks like something to remember for next April 1 ... :-)
--
Lou Steinberg
uucp: {pretty much any major site}!rutgers!aramis.rutgers.edu!lou
arpa: ···@aramis.rutgers.edu
In article <·····@iuvax.cs.indiana.edu> ······@iuvax.cs.indiana.edu (Dan Friedman) writes:
>Are there any LISP implementations, especially of Common LISP,
>which get 5 instead of 1 as the result of the following run?
>>>> (defun eval (x) 1)
Good grief, what's the point of this beyond proving that your lisp actually
calls a function named eval which isn't coded online in your toplevel loop?
Please explain.
From: ···@iuvax.cs.indiana.edu
Subject: Re: Question about eval
Date:
Message-ID: <20700006@iuvax>
> Good grief, what's the point of this beyond proving that your lisp actually
> calls a function named eval which isn't coded online in your toplevel loop?
> Please explain.
I think Dan wants to know if he can reliably redefine eval so that his own
eval is used by the top-level read-eval-print loop.
R. Kent Dybvig | arpa: ···@iuvax.cs.indiana.edu
Computer Science Department | usenet: ...!ihnp4!iuvax!dyb
Indiana University | ...!pyramid!iuvax!dyb
Bloomington, IN 47405 | phone: 812/335-6486
From: Barry Margolin
Subject: Re: Question about eval
Date:
Message-ID: <29266@think.UUCP>
In article <········@iuvax> ···@iuvax.cs.indiana.edu writes:
>I think Dan wants to know if he can reliably redefine eval so that his own
>eval is used by the top-level read-eval-print loop.
One of the proposals before X3J13 (the ANSI Common Lisp committee),
which I expect will be passed in a couple of months, specifies that
the effects of redefining any functions in the LISP package (i.e. any
function specified by the language standard) are undefined (it "is an
error", to use CLtL terminology). So, I wouldn't write any code that
does this at the moment.
Barry Margolin
Thinking Machines Corp.
······@think.com
{uunet,harvard}!think!barmar
From: Simon Brooke
Subject: Protection of core lisp fns (was: Re: Question about eval)
Date:
Message-ID: <589@dcl-csvax.comp.lancs.ac.uk>
In article <·····@think.UUCP> ······@kulla.think.com.UUCP (Barry Margolin) writes:
>In article <········@iuvax> ···@iuvax.cs.indiana.edu writes:
>>I think Dan wants to know if he can reliably redefine eval so that his own
>>eval is used by the top-level read-eval-print loop.
>
>One of the proposals before X3J13 (the ANSI Common Lisp committee),
>which I expect will be passed in a couple of months, specifies that
>the effects of redefining any functions in the LISP package (i.e. any
>function specified by the language standard) are undefined (it "is an
>error", to use CLtL terminology). So, I wouldn't write any code that
>does this at the moment.
>
I'd like to say 'What! you can't do that'; but of course you can. However you
have a *responsibility* not to do that. By setting yourselves up as the ANSI
CL Committee, you are effectively hegemonising your view of LISP, and imposing
it on the rest of the LISP community. This is acceptable only if the language
you produce is at least as expressive as the language(s) you are forcing us to
abandon. 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.
** Simon Brooke *********************************************************
* e-mail : ·····@uk.ac.lancs.comp *
* surface: Dept of Computing, University of Lancaster, LA 1 4 YW, UK. *
* *
* Thought for today: isn't it time you learned the Language *
********************* International Superieur de Programmation? *********
From: John Gateley
Subject: Re: Protection of core lisp fns (was: Re: Question about eval)
Date:
Message-ID: <61560@ti-csl.CSNET>
In article <···@dcl-csvax.comp.lancs.ac.uk> ·····@comp.lancs.ac.uk (Simon Brooke) writes:
>[...]
>abandon. 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.
>** Simon Brooke *********************************************************
Sure you can express these things if you want to: there is always *eval-hook*
and if that is not powerful enough, then you can write your own
read-eval-print loop. What you cannot do is redefine a symbol in the lisp
package. You can, however, by use of CL's package system, define your own
eval which would take the place of CL's eval in your programs only.
John
·······@mips.csc.ti.com
From: Barry Margolin
Subject: Re: Protection of core lisp fns (was: Re: Question about eval)
Date:
Message-ID: <29663@think.UUCP>
In article <···@dcl-csvax.comp.lancs.ac.uk> ·····@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.
······@think.com
{uunet,harvard}!think!barmar
From: Jeff Dalton
Subject: Re: Question about eval
Date:
Message-ID: <621@aiva.ed.ac.uk>
In article <·····@iuvax.cs.indiana.edu> ······@iuvax.cs.indiana.edu (Dan Friedman) writes:
>Are there any LISP implementations, especially of Common LISP,
>which get 5 instead of 1 as the result of the following run?
> (defun eval (x) 1); then 5 => 1
Yes, KCL.
>Does this change to eval ever change what load does?
No.
>Does (setf (symbol-function 'eval) #'(lambda (x) 1))
>do exactly the same thing as (defun eval (x) 1) in all
>Common Lisp implementations?
Probably not. DEFUN puts in a BLOCK, for one thing. Also,
I dont' think there's anyhting that requires it to set the
function value exactly the same way SETF of SYMBOL-FUNCTION
does.
If you want to redefine EVAL and be sure it works, I think
you have to make a new package that shadows EVAL and LOAD,
redefines them, and (depending on how you want to do this)
exports all the other symbols the LISP package does.
-- Jeff
From: David Harvey
Subject: Re: Question about eval
Date:
Message-ID: <747@wsccs.UUCP>
In article <·····@iuvax.cs.indiana.edu>, ······@iuvax.cs.indiana.edu (Dan Friedman) writes:
> Are there any LISP implementations, especially of Common LISP,
> which get 5 instead of 1 as the result of the following run?
>
> >>> (defun eval (x) 1)
> eval
>
> >>> 5
> 1
>
Yes, VAX' Common Lisp will return the value of 5. It will
also not let you so cavalierly redefine this system primitive. It
sqwawks about it in no uncertain terms before allowing you to hang
yourself. 5 returns 5, and (eval anyentity) returns 1. If you do
an explicit eval of anthing over or less than 1 arg it will complain
now.
> Does this change to eval ever change what load does?
>
> Does (setf (symbol-function 'eval) #'(lambda (x) 1))
> do exactly the same thing as (defun eval (x) 1) in all
> Common Lisp implementations?
>
> ... Dan
Unfortunately, VAX Common Lisp will not sqwawk at you when you
redefine in this manner. It accomplishes the same results as above.
Although I have not tried this with any other Common Lisp, the results
of the setf and the defun should be the same on all machines, since
the defun is nothing more than a macro that expands to the setf. Oops,
check that. This assumes that setf and defun are both found in package
Lisp. Where else would they be?
dharvey aliases: Lispin' Dave
Hacker Horribulus
I am responsible for Nobody,
and Nobody is responsible for me.
The only thing you can know for sure,
is that you can't know anything for sure.