Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!rutgers!cmcl2!yale!Krulwich-Bruce
From: Krulwich-Bruce@cs.yale.edu (Bruce Krulwich)
Newsgroups: comp.lang.lisp
Subject: Re: Redefining read-eval-print loop.
Message-ID: <41800@yale-celray.yale.UUCP>
Date: 31 Oct 88 17:33:19 GMT
References: <3185@mit-amt> <593@dcl-csvax.comp.lancs.ac.uk>
Sender: root@yale.UUCP
Reply-To: Krulwich-Bruce@cs.yale.edu (Bruce Krulwich)
Organization: Computer Science, Yale University, New Haven, CT 06520-2158
Lines: 24
In-reply-to: simon@comp.lancs.ac.uk (Simon Brooke)

In article <593@dcl-csvax.comp.lancs.ac.uk>, simon@comp (Simon Brooke) writes:
>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! The elegance 
>and power of LISP lie precisely in its simple, general semantics, and in its
>malleability. If the ANSI Lisp committee want to write in FORTRAN, that's
>fine, let them. BUT LEAVE MY LANGUAGE ALONE!

As I understand it, they have not made ANY changes to the semantics of the
language or of the set of function symbols.  All that has been proposed is
that the functions that are part of the language definition be effectively
declared INLINE.  (ie, that they can be changed but that the changes may
not propogate to all of their uses.) 

Any problems that you have with the changes are in fact problems with the
semantics of INLINE. 

On the other hand, the analogy between CL and Fortran may have some basis.
Issues such as the seperation of function and value slots seem to be decided
by arguments such as "that's the way it's always been" and "that's the way 
the implementations all work" and not "that's the better way to do it."


Bruce