From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: pjb@informatimago.com (Pascal J. Bourguignon) Newsgroups: gmane.emacs.help Subject: Re: identity function with an echo side effect Date: Wed, 11 Aug 2010 22:43:58 +0200 Organization: Informatimago Message-ID: <87bp98anht.fsf@kuiper.lan.informatimago.com> References: <324e9d4c-b083-42a3-aa88-4e7b918042e3@h32g2000yqm.googlegroups.com> <87eie6ax5b.fsf@kuiper.lan.informatimago.com> <87ocd99qps.fsf@kuiper.lan.informatimago.com> <106a3bf2-cd32-4b50-8e99-81e0cad8efa2@j8g2000yqd.googlegroups.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Trace: dough.gmane.org 1291857503 2349 80.91.229.12 (9 Dec 2010 01:18:23 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 9 Dec 2010 01:18:23 +0000 (UTC) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Thu Dec 09 02:18:14 2010 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1PQV9B-0000Mh-Rs for geh-help-gnu-emacs@m.gmane.org; Thu, 09 Dec 2010 02:18:14 +0100 Original-Received: from localhost ([127.0.0.1]:34318 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PQV9B-0005VZ-4F for geh-help-gnu-emacs@m.gmane.org; Wed, 08 Dec 2010 20:18:13 -0500 Original-Path: usenet.stanford.edu!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail Original-Newsgroups: gnu.emacs.help, comp.emacs, comp.emacs.xemacs, gnu.emacs, comp.lang.lisp Original-Lines: 236 Original-X-Trace: individual.net V2CDSl5vl6nbcc40EK15eg7AIp9KleloAcS3/iKsUZEVtMJ5+B Cancel-Lock: sha1:ZTMwNmU4ZmJlNTcyY2NlOTZiMjZhNWE1MzljMjgyMWEzZjI5MDYyMw== sha1:IouEb7ibB1RjUz6Tte1zd+oTFFM= Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwAQMAAABtzGvEAAAABlBMVEUAAAD///+l2Z/dAAAA oElEQVR4nK3OsRHCMAwF0O8YQufUNIQRGIAja9CxSA55AxZgFO4coMgYrEDDQZWPIlNAjwq9 033pbOBPtbXuB6PKNBn5gZkhGa86Z4x2wE67O+06WxGD/HCOGR0deY3f9Ijwwt7rNGNf6Oac l/GuZTF1wFGKiYYHKSFAkjIo1b6sCYS1sVmFhhhahKQssRjRT90ITWUk6vvK3RsPGs+M1RuR mV+hO/VvFAAAAABJRU5ErkJggg== X-Accept-Language: fr, es, en X-Disabled: X-No-Archive: no User-Agent: Gnus/5.101 (Gnus v5.10.10) Emacs/23.2 (gnu/linux) Original-Xref: usenet.stanford.edu gnu.emacs.help:180596 comp.emacs:100341 comp.emacs.xemacs:82491 comp.lang.lisp:291115 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:76368 Archived-At: bolega writes: > On Aug 11, 7:19 am, p...@informatimago.com (Pascal J. Bourguignon) > wrote: >> Since CDR and PRINT are function, no implicit quotation occurs: the >> result values are directly passed as argument to the next function. > > Then why does the following gives an error. Currently, I only have > elisp working so we confine to emacs runs. > > (cdr (print (cdr (print (cdr (print (a b c d))))))) C-x C-e > > gives this error if I remove the quote. why ? What are the rules of lisp evaluation? > I get errors if I remove > all prints. This means if the first cdr required quoted list, No. cdr requires a LIST. Nothing more, nothing less. > then the rest must also require it. print may take any lisp object as argument. cdr mak take any list. > Hence, an implicit quotation might be > occurring as in setq ? setq as its name implies indeed makes an implicit quotation. But not the one you may think. > Also, plz explain me the debugger output in > detail so I can figure it out myself. may be a line by line comment > and if there is a more comprehensive example you can cook, better for > all the readers, once and for all. > > Debugger entered--Lisp error: (void-function a) a is not a function, that is, the function slot of the symbol a is void. The rest is the backtrace: The error was detected when trying to evaluate this form: > (a b c d) which was to be evaluated because it was needed to evaluate this form: > (print (a b c d)) etc. > (cdr (print (a b c d))) > (print (cdr (print ...))) > (cdr (print (cdr ...))) > (print (cdr (print ...))) > (cdr (print (cdr ...))) > eval((cdr (print (cdr ...)))) > eval-last-sexp-1(nil) > eval-last-sexp(nil) > * call-interactively(eval-last-sexp) The rules of evaluation of lisp are something like: (defun eval. (form) (cond ((symbolp form) (symbol-value form)) ((atom form) form) (t (case (first form) ((quote function) (second form)) ((if) (if (eval. (second form)) (eval. (third form)) (let ((result)) (dolist (subform (cdddr form)) (setf result (eval. subform))) result))) ;; ... other special operator special rules here ... (otherwise (cond ((symbol-function (first form)) (apply. (symbol-function (first form)) (mapcar (function eval.) (rest form)))) ((macro-function (first form)) (eval. (macroexpand form))) (t (error "(void-function %S)" (first form))))))))) Quote is useless and worthless, you can write your programs without it. To get the symbol named "a", you may use the function intern. To build a list, you may use the function list. (let ((my-list (list (intern "a") (intern "b") (intern "c") (intern "d")))) (cdr (print (cdr (print (cdr (print my-list))))))) (a b c d) (b c d) (c d) (d) It just happen that when you read "(a b c d)", the lisp reader just calls intern and list like you would. So you could also write, in emacs lisp: (let ((my-list (car (read-from-string "(a b c d)")))) (cdr (print (cdr (print (cdr (print my-list))))))) (in Common Lisp, READ-FROM-STRING returns two values, instead of returning one cons cell with the two values, so the CAR would be superfluous). But also, it happens that: (car (read-from-string "(a b c d)")) returns: (a b c d) and that lisp programs are read by the same lisp reader used by read-from-string. Therefore if you write (a b c d) in your program, what will be read is exactly the same as the list you would build with list and intern, or read with read-from-string. There's just a little problem, that what is read in a program is also evaluated! And (a b c d) is not a symbol, it's not an atom, and its first element is not quote, if, or any other special operator defined in lisp, therefore eval will check if it is a function. Since a is not defined as a function, and it is not defined as a macro, eval will fall down in the latest case, were it will report the error that a is not a function. Any expression in a program will be executed! This is the point of being a program, to be executed (by eval). So how can we insert in a program some literal data. For example, what happens when we evaluate the expression: 42 ? It is not a symbol. But it is an atom. And when it's an atom, eval will return it as is. non-symbol atoms are self-evaluating. Therefore the value (the result of evaluating) 42 is 42. We're quite lucky that numbers are worth themselves! For non atoms, we must use the special operator quote, because otherwise they would be evaluated as an operator application. (quote 42) is not a symbol, is not an atom (it's a cons cell), but it's first element is the symbol quote. In that case, eval returns the second elements, that is, 42. Therefore: (quote 42) evaluates to 42 which is the same as what: 42 evaluates to. (eql '42 42) evaluates to true! But this is something that is specific to non-symbol atoms (and some symbols, that are bound to themselves such as nil, t, or any other variable you'd bind to their symbol). (quote (a b c d)) is not a symbol, is not an atom, is a list whose first element is quote, therefore eval returns the second elements, which happens to be the list: (a b c d) Therefore (quote (a b c d)) evaluates to: (a b c d) Hence we have a way to produce a literal list in a program, by using quote. (cdr (print (cdr (print (cdr (print (quote (a b c d)))))))) (a b c d) (b c d) (c d) (d) But there is no quoted lists, no more that there is any quoted number or quoted string or quoted anything. The only thing there is, is some literal data in a program. And you should not modify any literal data because that would mean modifying the program in some uncontrolled way, and you'd get unpreditable results. But apart from this, literal data is data like any other data. -- __Pascal Bourguignon__ http://www.informatimago.com/