unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Dmitry Gutov <dgutov@yandex.ru>
To: "Drew Adams" <drew.adams@oracle.com>
Cc: 'xfq' <xfq.free@gmail.com>, emacs-devel@gnu.org
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	[thread overview]
Message-ID: <87txmz2ukn.fsf@yandex.ru> (raw)
In-Reply-To: <C01B0F21EB3D4CE5B393F2461DE379C9@us.oracle.com> (Drew Adams's message of "Sun, 21 Apr 2013 11:04:07 -0700")

"Drew Adams" <drew.adams@oracle.com> 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.



  parent reply	other threads:[~2013-04-22  2:00 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <E1UTtCq-0003Tj-Lr@vcs.savannah.gnu.org>
2013-04-21 12:39 ` /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 than special forms. (Bug#13853) Leo Liu
2013-04-21 13:00   ` xfq
2013-04-21 14:00     ` Dmitry Gutov
2013-04-21 16:55       ` /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 " Drew Adams
2013-04-21 17:14         ` Dmitry Gutov
2013-04-21 17:55           ` Stephen J. Turnbull
2013-04-22  1:47             ` Dmitry Gutov
2013-04-21 18:04           ` Drew Adams
2013-04-21 18:57             ` Stephen J. Turnbull
2013-04-21 19:40               ` /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 ratherthanspecial " Drew Adams
2013-04-22  1:21                 ` Stephen J. Turnbull
2013-04-22  1:35                   ` /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 macrosratherthanspecial " Drew Adams
2013-04-22  2:00             ` Dmitry Gutov [this message]
2013-04-21 18:07       ` /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 than special " Glenn Morris
2013-04-21 22:54         ` xfq
2013-04-22 17:02           ` Glenn Morris
2013-04-23  0:47             ` Xue Fuqiao
2013-04-23 16:42               ` Glenn Morris
2013-04-23 22:28                 ` Xue Fuqiao
2013-04-22  3:17         ` Leo Liu
2013-04-22 10:31           ` xfq
2013-04-22 14:11             ` Leo Liu
2013-04-22 14:19               ` Dmitry Gutov
2013-04-22 15:37                 ` Leo Liu
2013-04-22 14:47   ` Stefan Monnier

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87txmz2ukn.fsf@yandex.ru \
    --to=dgutov@yandex.ru \
    --cc=drew.adams@oracle.com \
    --cc=emacs-devel@gnu.org \
    --cc=xfq.free@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).