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: Mon, 22 Apr 2013 06:00:24 +0400 Message-ID: <87txmz2ukn.fsf@yandex.ru> References: <87obd8rnk1.fsf@yandex.ru> <51741E72.8030204@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1366596041 21872 80.91.229.3 (22 Apr 2013 02:00:41 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 22 Apr 2013 02:00: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 Mon Apr 22 04:00:44 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 1UU63Y-0003ga-Oc for ged-emacs-devel@m.gmane.org; Mon, 22 Apr 2013 04:00:36 +0200 Original-Received: from localhost ([::1]:46097 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UU63Y-0000Bj-Bv for ged-emacs-devel@m.gmane.org; Sun, 21 Apr 2013 22:00:36 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:51988) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UU63R-0000BR-8R for emacs-devel@gnu.org; Sun, 21 Apr 2013 22:00:34 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UU63M-00045H-NI for emacs-devel@gnu.org; Sun, 21 Apr 2013 22:00:29 -0400 Original-Received: from mail-la0-x236.google.com ([2a00:1450:4010:c03::236]:64042) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UU63M-00045D-F9 for emacs-devel@gnu.org; Sun, 21 Apr 2013 22:00:24 -0400 Original-Received: by mail-la0-f54.google.com with SMTP id es20so1126505lab.41 for ; Sun, 21 Apr 2013 19:00:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-type:x-antivirus :x-antivirus-status; bh=nkkAflb5NcvMubvYe4rlN2aU0OrGYdX9kn0mKHbV3F0=; b=NIR8BNCPDPL8b6yD5OAnWJYijAtVG/ZKHpjtz8VeQNSdYnaXoZaUD9ahU+96TAgO1C J8PWPXD6RcPl9vLbFZiJ9JcUNNWUObWUArpwZoWwnDvjFd6l/q/B7Z9TqTzm04b7U9TO ZmXTEYPnwM+jXVl23mj8wF0v4+hsD5YDs5EhogoxxbfnH8tYsOXffRAtYeKj5xHwH7jq +gfDO9Wd1mLtneZtzbHABF2yHPLOALuZqF8el5wkZzFQKIWWlMCSK3Sj3k+IeGyJItfB gmwhAhDVrY/7bK+wmcgRPdFcS5sP2pTxy7BqlIeLrSgFgQIXOXo+wjebCJT8RMd7gR1K JVng== X-Received: by 10.112.125.33 with SMTP id mn1mr12246789lbb.89.1366596023354; Sun, 21 Apr 2013 19:00:23 -0700 (PDT) Original-Received: from SOL ([178.252.98.87]) by mx.google.com with ESMTPS id t20sm9677425lbi.5.2013.04.21.19.00.21 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 21 Apr 2013 19:00:22 -0700 (PDT) In-Reply-To: (Drew Adams's message of "Sun, 21 Apr 2013 11:04:07 -0700") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (windows-nt) X-Antivirus: avast! (VPS 130421-1, 21.04.2013), Outbound message X-Antivirus-Status: Clean X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:4010:c03::236 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:159101 Archived-At: "Drew Adams" writes: >> > 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. Looks like I misunderstood that part of the text (see my other reply), "special operators" are cars of "special forms". IIU it correctly now, "special form" is a "special operator" application, together with the arguments: http://www.lispworks.com/documentation/HyperSpec/Body/26_glo_s.htm#special_form With that terminilogy, "special operator" in CL = "special form" in Elisp. > 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). That's the core of my objection, actually. It doesn't seem to me that the way the special form is implemented is particularly relevant at that point of the manual. Providing too much details will mostly result in more situations when the manual has to be corrected. Like in this case, when `defun' implementation moved from C to Elisp in Emacs 24.3. > `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. True.