unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: "Drew Adams" <drew.adams@oracle.com>
To: "'Dmitry Gutov'" <dgutov@yandex.ru>, "'xfq'" <xfq.free@gmail.com>
Cc: emacs-devel@gnu.org
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	[thread overview]
Message-ID: <CFE6067128234387809B7128068D380E@us.oracle.com> (raw)
In-Reply-To: <87obd8rnk1.fsf@yandex.ru>

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

> 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	other threads:[~2013-04-21 16:55 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <E1UTtCq-0003Tj-Lr@vcs.savannah.gnu.org>
2013-04-21 12:39 ` /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 than special forms. (Bug#13853) Leo Liu
2013-04-21 13:00   ` xfq
2013-04-21 14:00     ` Dmitry Gutov
2013-04-21 16:55       ` Drew Adams [this message]
2013-04-21 17:14         ` /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 " Dmitry Gutov
2013-04-21 17:55           ` Stephen J. Turnbull
2013-04-22  1:47             ` Dmitry Gutov
2013-04-21 18:04           ` Drew Adams
2013-04-21 18:57             ` Stephen J. Turnbull
2013-04-21 19:40               ` /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 ratherthanspecial " Drew Adams
2013-04-22  1:21                 ` Stephen J. Turnbull
2013-04-22  1:35                   ` /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 macrosratherthanspecial " Drew Adams
2013-04-22  2:00             ` /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 " Dmitry Gutov
2013-04-21 18:07       ` /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 than special " Glenn Morris
2013-04-21 22:54         ` xfq
2013-04-22 17:02           ` Glenn Morris
2013-04-23  0:47             ` Xue Fuqiao
2013-04-23 16:42               ` Glenn Morris
2013-04-23 22:28                 ` Xue Fuqiao
2013-04-22  3:17         ` Leo Liu
2013-04-22 10:31           ` xfq
2013-04-22 14:11             ` Leo Liu
2013-04-22 14:19               ` Dmitry Gutov
2013-04-22 15:37                 ` Leo Liu
2013-04-22 14:47   ` Stefan Monnier

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CFE6067128234387809B7128068D380E@us.oracle.com \
    --to=drew.adams@oracle.com \
    --cc=dgutov@yandex.ru \
    --cc=emacs-devel@gnu.org \
    --cc=xfq.free@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).