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)

[Dmitry Gutov]

"Drew Adams" <address@hidden> 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.