From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: TheFlyingDutchman Newsgroups: gmane.emacs.help Subject: Re: identity function with an echo side effect Date: Wed, 11 Aug 2010 19:35:47 -0700 (PDT) Organization: http://groups.google.com Message-ID: <4a9f81c6-9763-45bb-ae17-11aaadc198f3@x24g2000pro.googlegroups.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 X-Trace: dough.gmane.org 1291858142 4407 80.91.229.12 (9 Dec 2010 01:29:02 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 9 Dec 2010 01:29:02 +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:28:58 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 1PQVJZ-0004Cw-3x for geh-help-gnu-emacs@m.gmane.org; Thu, 09 Dec 2010 02:28:57 +0100 Original-Received: from localhost ([127.0.0.1]:43167 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PQVJY-0002rs-AT for geh-help-gnu-emacs@m.gmane.org; Wed, 08 Dec 2010 20:28:56 -0500 Original-Path: usenet.stanford.edu!postnews.google.com!x24g2000pro.googlegroups.com!not-for-mail Original-Newsgroups: gnu.emacs.help, comp.emacs, comp.emacs.xemacs, gnu.emacs, comp.lang.lisp Original-Lines: 40 Original-NNTP-Posting-Host: 76.201.171.123 Original-X-Trace: posting.google.com 1281580547 2679 127.0.0.1 (12 Aug 2010 02:35:47 GMT) Original-X-Complaints-To: groups-abuse@google.com Original-NNTP-Posting-Date: Thu, 12 Aug 2010 02:35:47 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: x24g2000pro.googlegroups.com; posting-host=76.201.171.123; posting-account=9bWHAAoAAAAxSFC_2O_ssTETNW9NhMbW User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; Trident/4.0; GTB6.5; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; AskTbBT5/5.8.0.12304),gzip(gfe) Original-Xref: usenet.stanford.edu gnu.emacs.help:180605 comp.emacs:100343 comp.emacs.xemacs:82492 comp.lang.lisp:291124 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:76385 Archived-At: > (cdr (print (cdr (print (cdr (print (a b c d))))))) C-x C-e > > gives this error if I remove the quote. why ? I get errors if I remove > all prints. This means if the first cdr required quoted list, then the > rest must also require it. Hence, an implicit quotation might be > occurring as in setq ? Each cdr requires the same thing - a list object. The first cdr does not receive "(a b c d)" as its argument, it receives that list literal turned into its in-memory representation as a list object. Each cdr returns a list object (the internal format - not a string literal) to the next cdr. The Emacs Lisp interpreter has to turn the (a b c d) "list literal" into a list object before passing it to the first cdr function. However, Emacs Lisp has a problem that most languages do not have. A list literal looks exactly the same as a function call. e.g.: (min a b) => Emacs Lisp function call OR Emacs Lisp list literal The above could be a list, with symbols min, a and b. Or it could be a function call of min with parameters a and b. In contrast, the Python interpreter would not have a problem differentiating between the two because there is different syntax for each: min(a ,b) => Python function call [min, a, b] => Python list literal So how does the Emacs Lisp interpreter differentiate between a function call and a list literal? It doesn't. It assumes everything is a function call - or similar expression (macro, special form). If you are actually writing a list literal and not an expression to evaluate, you have to explicitly tell the Emacs Lisp interpreter not to evaluate it as an expression, but to just store it as a list object. so (a b c d) to Emacs Lisp is a call to the function of symbol a, and it should pass b, c and d as parameters. '(a b c d) or (quote (a b c d)) tells Emacs Lisp not to try and execute any function stored in a - just store the whole thing as a list internally.