[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: /srv/bzr/emacs/trunk r112347: *doc/lispintro/emacs-lisp-intro.texi (

From: Dmitry Gutov
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: Sun, 21 Apr 2013 21:14:26 +0400
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5

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

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)

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


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

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]