[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: Drew Adams
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 09:55:57 -0700

> (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_. ;-)

(eintr) does not try to be precise here, which would involve saying that _some_
thingies that do not work in the usual manner are special forms.  And it does
not say precisely what "work in the usual manner" involves.

These things are not the point of that presentation, which is to _introduce_ you
to the fact that some sexps are handled differently.  (It would also not speak
so loosely of "functions" here, if it were trying to be precise.)

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

Teaching often involves stages at which what is said is only partly true (i.e.,
is a lie).  Fuller truths come later.  Perhaps (eintr) provides a fuller
understanding about special forms later on - dunno.  But the point is that those
sentences are not a specification of what we mean by "special form".  They are
just a partial indication and provide only partial help.

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)

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

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

reply via email to

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