Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!ames!amdcad!sun!pitstop!sundc!seismo!uunet!mcvax!ukc!etive!aiva!jeff
From: jeff@aiva.ed.ac.uk (Jeff Dalton)
Newsgroups: comp.lang.lisp
Subject: Re: Redefining read-eval-print loop.
Message-ID: <623@aiva.ed.ac.uk>
Date: 26 Oct 88 21:18:57 GMT
References: <3185@mit-amt> <593@dcl-csvax.comp.lancs.ac.uk>
Reply-To: jeff@uk.ac.ed.aiva (Jeff Dalton)
Organization: Dept. of AI, Univ. of Edinburgh, UK
Lines: 55

In article <593@dcl-csvax.comp.lancs.ac.uk> simon@comp.lancs.ac.uk (Simon
Brooke) writes:
>>	It is still possible to redefine the way the read-eval-print
>>loop works; you just have to wrap your own read-eval-print loop

>Yes, ok, there are butchers jobs you can use to work round any barbarity.

I am not convinced that redefining EVAL is the best way to get a
different repl.  Indeed, writing a new loop is often a better way.

> They now propose a futher barbarity: they propose to alter the
> system so that a class of function symbols has a different semantics
> from all other function symbols. This *cannot* be a good thing to do!

It prevents you from breaking the Lisp unintentionally and it prevents
you from thinking you have code that will work in more than one
implementation when you don't.  So there are points on both sides.

Besides, suppose they let you lock a package in the same way that the
Lisp package would be locked.  Then the no-redefinition semantics for
the Lisp package would not be a special case.

> The elegance and power of LISP lie precisely in its simple, general
> semantics, and in its malleability.

Well, suppose you redefine some function.  How do you know what other
functions will see that redefinition and what ones will not?  If you
redefine EVAL, will it change the behavior of LOAD?  Historically the
answer has been: it depends on the implementation.  I have yet to
see a specification for a Lisp *as a language rather than as an
implementation* that described what happened in all these cases.

Redefining built-in procedures generally has unpredictable
consequences.  Sometimes, everything falls apart.  Other times,
it has surprisingly little effect.  Getting the exact reaults
you want is generally impossible except where you know the details
of a particular implementation.

And particular implementations might not have let your redefinitions
have any effect in any case.  (Imagine, for example, that everything
is "block compiled" so that redefinitions are never seen by internal
calls.  You could redefine EVAL then and it wouldn't even change the
repl.)

So what, exactly, do you want?  Do you want CL to leave this area
unspecified?  Do you want a specification of exactly what happens
in every case?  Or do you just want the top-level loop defined in
such a way that you can change the read, eval, and print parts?

> If the ANSI Lisp committee want to write in FORTRAN, that's fine,

But they don't want to write in FORTRAN, they want to write in
Common Lisp.

-- Jeff