simon@comp.lancs.ac.uk (Simon Brooke) (10/17/88)
In article <29266@think.UUCP> barmar@kulla.think.com.UUCP (Barry Margolin) writes: >In article <20700006@iuvax> dyb@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 : simon@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? *********
gateley@mips.csc.ti.com (John Gateley) (10/22/88)
In article <589@dcl-csvax.comp.lancs.ac.uk> simon@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 gateley@mips.csc.ti.com
barmar@think.COM (Barry Margolin) (10/24/88)
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