From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.devel Subject: RE: /srv/bzr/emacs/trunk r112347: *doc/lispintro/emacs-lisp-intro.texi (defcustom, defun, simplified-beginning-of-buffer, defvar, Building Robots, Review, save-excursion): `defun' and `defcustom' are now macros rather thanspecial forms. (Bug#13853) Date: Sun, 21 Apr 2013 11:04:07 -0700 Message-ID: References: <87obd8rnk1.fsf@yandex.ru> <51741E72.8030204@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1366567474 3514 80.91.229.3 (21 Apr 2013 18:04:34 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 21 Apr 2013 18:04:34 +0000 (UTC) Cc: 'xfq' , emacs-devel@gnu.org To: "'Dmitry Gutov'" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Apr 21 20:04:37 2013 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1UTyco-0007OH-4p for ged-emacs-devel@m.gmane.org; Sun, 21 Apr 2013 20:04:30 +0200 Original-Received: from localhost ([::1]:46683 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UTycn-0006W5-EH for ged-emacs-devel@m.gmane.org; Sun, 21 Apr 2013 14:04:29 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:45862) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UTyck-0006Vk-9S for emacs-devel@gnu.org; Sun, 21 Apr 2013 14:04:27 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UTycj-0002IR-0x for emacs-devel@gnu.org; Sun, 21 Apr 2013 14:04:26 -0400 Original-Received: from userp1040.oracle.com ([156.151.31.81]:26947) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UTyci-0002IN-Qc for emacs-devel@gnu.org; Sun, 21 Apr 2013 14:04:24 -0400 Original-Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r3LI4Lsx012318 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 21 Apr 2013 18:04:22 GMT Original-Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r3LI4KCF011305 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 21 Apr 2013 18:04:21 GMT Original-Received: from abhmt117.oracle.com (abhmt117.oracle.com [141.146.116.69]) by userz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r3LI4Ke8018674; Sun, 21 Apr 2013 18:04:20 GMT Original-Received: from dradamslap1 (/71.202.147.44) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 21 Apr 2013 11:04:19 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <51741E72.8030204@yandex.ru> Thread-Index: Ac4+s7Bo6fM5r+iKRvCQrMtjFalj9QAAh7MQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] X-Received-From: 156.151.31.81 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:159086 Archived-At: > > Emacs Lisp is not alone in using the term "special form". > > The term is used in other Lisps as well. It distinguishes > > sexps that are not evaluated at the Lisp level, in particular > > not evaluated as Lisp macro applications. > > Not so. > http://www.lispworks.com/documentation/HyperSpec/Body/03_ababa.htm > http://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node59.html > http://www.nhplace.com/kent/Papers/Special-Forms.html Yes, that is all true, and it provides an appropriate correction to what I stated. When Emacs Lisp becomes a standard that has multiple implementations (e.g. C, Scheme, whatever) then it might make sense for it too to adopt a similar approach (which essentially is that implementations are free to implement special forms any way they like). For now there is one Emacs Lisp implementation, and (I think) only one meaning of "special form", which excludes the possibility that something be both a special form and a Lisp macro. There is no distinction of "special operators", for instance. Someone will correct me if I'm wrong here. The real point, I think, of Fuqiao's bug fix is that "macro" is more precise than "special form". And that is the case for Common Lisp etc. as well. If you know that something (e.g. `defun') is a macro then you know how it is implemented (as a macro!). If you know only that something (e.g. `setq') is a special form then (in Common Lisp) you know next to nothing about how it is implemented (without consulting the implementation doc or code). > > And they are typically NOT "functions", BTW. > > (functionp 'setq) => nil > > Macros are also "not functions" by this definition. By `functionp': (defmacro foo (a) 42) (functionp 'foo) => t (Before autoloading of macros and keymaps, any symbol that was `fboundp' was also `functionp'. Now autoloaded symbols that load macros or keymaps are not `functionp'.) `special-form-p', as far as that speaks to the question, tells us that to be a special form in Emacs Lisp something must be (directly or indirectly) `subrp', i.e., built-in. > > (Lots of talk about Lisp uses "function" in various > > informal ways, including reference to the car of any cons > > sexp to be evaluated. This is generally OK, provided things ^^^^^^^^^^^^^^^^^^^^ > > are clear from the context. Lisp is a _somewhat_ functional > > language, after all.) > > I dunno, calling anything that can be used as a car of an evaluatable > sexp a "function" makes sense in general context. We agree about that. But the context needs to be clear. If talking outside Lispdom, to a Haskellite, for instance, it behooves us to make clear that such a "function" in Lisp is not necessarily a function in the usual, math sense.