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: Purpose of dash # in elisp Date: Mon, 09 Nov 2009 14:00:33 +0100 Organization: Informatimago Message-ID: <87k4xz7szy.fsf@galatea.local> References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1257774128 29538 80.91.229.12 (9 Nov 2009 13:42:08 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 9 Nov 2009 13:42:08 +0000 (UTC) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Mon Nov 09 14:42:01 2009 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.50) id 1N7UVH-0001DW-DQ for geh-help-gnu-emacs@m.gmane.org; Mon, 09 Nov 2009 14:41:55 +0100 Original-Received: from localhost ([127.0.0.1]:41151 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1N7UVG-0008Dt-Qz for geh-help-gnu-emacs@m.gmane.org; Mon, 09 Nov 2009 08:41:54 -0500 Original-Path: news.stanford.edu!usenet.stanford.edu!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail Original-Newsgroups: gnu.emacs.help Original-Lines: 101 Original-X-Trace: individual.net X73kAF+PdvkewkuEKwuebw2bRtNKoOP98ZYx+gcZ0DiQbwuSRO Cancel-Lock: sha1:ZDc2ZjcxOTRiMDBlMTVlNTA5N2MxNTZkOTEwNDQ1MGVmOGNiMzM0ZQ== sha1:Du+C5T5V3SzSrW2uKr5Dz8peqds= 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.1008 (Gnus v5.10.8) Emacs/22.3 (darwin) Original-Xref: news.stanford.edu gnu.emacs.help:174549 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:69624 Archived-At: Tassilo Horn writes: > Nordlöw writes: > >> What purpose does # as a quote suffix? > > You mean as prefix, e.g. > > (mapcar #'oddp '(1 2 3)) > > versus > > (mapcar 'oddp '(1 2 3))? > > Both forms are completely equivalent (try disassembling them), but the > former is more common to a common lisp programmer, where you pass > function symbols with the `function' macro and its reader form #', and > other symbols that should not be evaled with `quote' (which is '). > > If you stick to the convention to always use #' when passing a function > as arguments, the code might be a littlebit more explanatory, because > then you can see that a function is passed on a first glance. On the > other hand, in elisp the reader won't error or warn if you use #' to > pass anything different, so this convention wouldn't be enforced > somehow. (first ' #'x) --> function (first ' 'x) --> quote It happens that in emacs lisp, function and quote evaluate the same: they both return their unevaluated argument unchanged. However, when compiling, they don't behave the same. function means that the argument is CODE, while quote says that the argument is DATA. (disassemble (byte-compile (lambda () '(lambda (x) (+ x x))))) produces: byte code: args: nil 0 constant (lambda (x) (+ x x)) 1 return (disassemble (byte-compile (lambda () #'(lambda (x) (+ x x))))) produces: byte code: args: nil 0 constant args: (x) 0 varref x 1 dup 2 plus 3 return 1 return When the lambda form is quoted, it is considered data, and the compiler doesn't compile it, but when it's function'ed, it is considered code, and it is compiled too. Notice that lambda itself is a macro that expands to a function form: (macroexpand '(lambda (x) (+ x x))) --> (function (lambda (x) (+ x x))) Nonetheless some programmers (not me) like to prefix lambda forms with #': (mapcar #'(lambda (x) (+ x x)) '(1 2 3)) I just write: (mapcar (lambda (x) (+ x x)) '(1 2 3)) which compiles to the same. On the other hand, compiling: (mapcar '(lambda (x) (+ x x)) '(1 2 3)) wouldn't compile the lambda form, and therefore would produce slower code in general. In the case of function names, 'fun or #'fun will indeed produce the same results in all cases, in emacs lisp (in Common Lisp they would produce different results in some situations). emacs lisp: 'sin --> sin #'sin --> sin Common Lisp: 'sin --> SIN #'sin --> # -- __Pascal Bourguignon__