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 <dgutov@yandex.ru>]

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.