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 09:55:57 -0700 Message-ID: References: <87obd8rnk1.fsf@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 1366563378 31248 80.91.229.3 (21 Apr 2013 16:56:18 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 21 Apr 2013 16:56:18 +0000 (UTC) Cc: emacs-devel@gnu.org To: "'Dmitry Gutov'" , "'xfq'" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Apr 21 18:56:22 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 1UTxYq-0001ju-M0 for ged-emacs-devel@m.gmane.org; Sun, 21 Apr 2013 18:56:20 +0200 Original-Received: from localhost ([::1]:56074 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UTxYq-0007mV-D9 for ged-emacs-devel@m.gmane.org; Sun, 21 Apr 2013 12:56:20 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:51029) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UTxYm-0007mF-I6 for emacs-devel@gnu.org; Sun, 21 Apr 2013 12:56:18 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UTxYk-0001rc-Rx for emacs-devel@gnu.org; Sun, 21 Apr 2013 12:56:16 -0400 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:43312) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UTxYk-0001rU-MM for emacs-devel@gnu.org; Sun, 21 Apr 2013 12:56:14 -0400 Original-Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r3LGuBSL015653 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 21 Apr 2013 16:56:12 GMT Original-Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r3LGuABE008579 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 21 Apr 2013 16:56:11 GMT Original-Received: from abhmt119.oracle.com (abhmt119.oracle.com [141.146.116.71]) by userz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r3LGuA1b002266; Sun, 21 Apr 2013 16:56:10 GMT Original-Received: from dradamslap1 (/71.202.147.44) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 21 Apr 2013 09:56:10 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <87obd8rnk1.fsf@yandex.ru> Thread-Index: Ac4+mKQitC/jLbMfScGnAv5k6O1WtAAE6IuA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] X-Received-From: 141.146.126.69 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:159080 Archived-At: > (info "(eintr) Complications") says: > The second complication occurs because some functions are > unusual and do not work in the usual manner. Those that don't > are called "special forms". > > That means, any "unusual" function is a special form, including > macros. It says that, but that does not _mean_ that that is what the term "special form" _means_. ;-) (eintr) does not try to be precise here, which would involve saying that _some_ thingies that do not work in the usual manner are special forms. And it does not say precisely what "work in the usual manner" involves. These things are not the point of that presentation, which is to _introduce_ you to the fact that some sexps are handled differently. (It would also not speak so loosely of "functions" here, if it were trying to be precise.) The citation is from a _guide to learning_ Emacs Lisp, not from the Elisp manual, which is closer to being a reference manual. The sentences cited are aimed at helping a reader learn progressively. They do not precisely _define_ "special form". Teaching often involves stages at which what is said is only partly true (i.e., is a lie). Fuller truths come later. Perhaps (eintr) provides a fuller understanding about special forms later on - dunno. But the point is that those sentences are not a specification of what we mean by "special form". They are just a partial indication and provide only partial help. IOW, the (eintr) presentation is about _pedagogy_, which has a license to lie and a promise to reveal more and more truth (and often more complexity) progressively. > This page, however (I couldn't find it through the Info interface), > http://www.gnu.org/software/emacs/manual/html_node/elisp/Special-Forms.html > says that only primitive functions can be called special forms. > > I believe that this conflict should be resolved in favor of > the former 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. > > I think cross reference(s) to the `Lisp macro' node is a better than > > revert this change. > > IOW, the change should be reverted, and the manual should be > updated not to state that special forms are necessarily primitive > functions. No, they are implemented below/outside Lisp. This is the way, in Emacs Lisp as in some other Lisps. And they are typically NOT "functions", BTW. (functionp 'setq) => nil C-h f setq => "setq is a special form in `C source code'." That is another way in which (eintr) does not always-and-immediately "tell the truth, the whole truth, and nothing but the truth". It talks informally about such thingies as "functions", because doing can help you get where you need to go. It does not (should not anyway) lie gratuitously, but it does sometimes lie in order to help you get to the truth. (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.)