From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dmitry Gutov 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 21:14:26 +0400 Message-ID: <51741E72.8030204@yandex.ru> References: <87obd8rnk1.fsf@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1366564481 8888 80.91.229.3 (21 Apr 2013 17:14:41 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 21 Apr 2013 17:14:41 +0000 (UTC) Cc: 'xfq' , emacs-devel@gnu.org To: Drew Adams Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Apr 21 19:14:45 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 1UTxqc-00069n-1O for ged-emacs-devel@m.gmane.org; Sun, 21 Apr 2013 19:14:42 +0200 Original-Received: from localhost ([::1]:33391 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UTxqb-0003LO-Fq for ged-emacs-devel@m.gmane.org; Sun, 21 Apr 2013 13:14:41 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:55413) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UTxqU-0003L9-0g for emacs-devel@gnu.org; Sun, 21 Apr 2013 13:14:38 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UTxqP-0008In-Ma for emacs-devel@gnu.org; Sun, 21 Apr 2013 13:14:33 -0400 Original-Received: from mail-lb0-f174.google.com ([209.85.217.174]:55385) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UTxqP-0008IQ-Bs for emacs-devel@gnu.org; Sun, 21 Apr 2013 13:14:29 -0400 Original-Received: by mail-lb0-f174.google.com with SMTP id s10so5019152lbi.19 for ; Sun, 21 Apr 2013 10:14:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding:x-antivirus:x-antivirus-status; bh=tpucepO78++Vc1F/U+8Sx5vNZddC/4XxJvd98F1/Exo=; b=ZHcdQYhSTKAvX6SPYUsxFQer13TYRPBe20TtLSTZ3MB8ByieLduadKfFdSTJan0IiM bxyZhDolhmnvYZa3qoIPItWk61ohUrK+89/4eVP5PrbaVvlMRRjeww7a/FwYVCH/n33t tvxn6FYpfLoLX9fccEQHYx6axcDIxQYyu1xdNqhFQmHTaBbFGGN9Ja11Q159K15850Xy MzAFyeCQMDmFR6zKy5zqak/XB3N59vCR77srWRA+eOv3xlcEGP3NYMFCSQtabkABcdul I+dwivTbo1dxvrEFovS16r/Tg5d5o9LRDPfQY+YwKlHSJRhRz3F7DVcoDJ3VxQx9fC4+ 6iGA== X-Received: by 10.112.142.234 with SMTP id rz10mr10240270lbb.5.1366564468166; Sun, 21 Apr 2013 10:14:28 -0700 (PDT) Original-Received: from [127.0.0.1] ([178.252.98.87]) by mx.google.com with ESMTPS id a9sm9569060laf.2.2013.04.21.10.14.26 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 21 Apr 2013 10:14:27 -0700 (PDT) User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 In-Reply-To: X-Antivirus: avast! (VPS 130421-0, 21.04.2013), Outbound message X-Antivirus-Status: Clean X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [fuzzy] X-Received-From: 209.85.217.174 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:159081 Archived-At: On 21.04.2013 20:55, Drew Adams wrote: >> (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_. ;-) Yes, that's just what the text says. Whether it's absolutely true is indeed up to discussion. > 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". Indeed, they don't. And that may be the problem. > 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. Maybe so, but I don't think that lying at that exact point is advisable. >> 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. Not so. At least, I can give you a few examples from documents scattered around the Internet (primarily dealing with Common Lisp) that support the other position. http://www.lispworks.com/documentation/HyperSpec/Body/03_ababa.htm distinguishes between "special forms" and "special operators", and the latter ones are indeed the set of special forms that are usually implemented as primitives. http://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node59.html says: "An implementation is free to implement as a macro any construct described herein as a special form. Conversely, an implementation is free to implement as a special form any construct described herein as a macro if an equivalent macro definition is also provided. The practical consequence is that the predicates macro-function and special-form-p may both be true of the same symbol." http://www.nhplace.com/kent/Papers/Special-Forms.html starts with: "Special forms are those expressions in the Lisp language which do not follow normal rules for evaluation. Some such forms are necessary as primitives of the language, while others may be desirable in order to improve readability, control the evaluation environment, implement abstraction and modularity, affect the flow of control, allow extended scoping mechanisms, define functions which accept a variable number of arguments, or achieve greater efficiency. There exist several long-standing mechanisms for specifying the definition of special forms: FEXPR's, NLAMBDA's, and MACRO's." > >>> 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 Macros are also "not functions" by this definition. > 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.) I dunno, calling anything that can be used as a car of an evaluatable sexp a "function" makes sense in general context.