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)

["Drew Adams" <drew.adams@oracle.com>]

> > 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.

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).

> > And they are typically NOT "functions", BTW.
> > (functionp 'setq) => nil
> 
> Macros are also "not functions" by this definition.

By `functionp':
(defmacro foo (a) 42)
(functionp 'foo) => t

(Before autoloading of macros and keymaps, any symbol that was `fboundp' was
also `functionp'.  Now autoloaded symbols that load macros or keymaps are not
`functionp'.)

`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.

> > (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.

We agree about that.

But the context needs to be clear.  If talking outside Lispdom, to a Haskellite,
for instance, it behooves us to make clear that such a "function" in Lisp is not
necessarily a function in the usual, math sense.