emacs-devel
[Top][All Lists]
Advanced

[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: Mon, 22 Apr 2013 05:47:36 +0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (windows-nt)

"Stephen J. Turnbull" <address@hidden> writes:

> Dmitry Gutov writes:
>
>  > 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.
>
> This is much broader than common usage, though, since it explicitly
> includes macros.
>
> In Commmon Lisp, which has a very narrow (extensional) definition of
> "special form"[1], it seems to me the intent of the definition is to
> describe those features of the language which are "unfunctional".

Ah, I see now. The definition is on the separate page, and there it says
that a special form != macro form, and the car of a special form must be
a special operator (from the predefined list):

http://www.lispworks.com/documentation/HyperSpec/Body/26_glo_s.htm#special_form

So at least that spec agrees with the narrow definition, as well as
with `special-form-p' implementation (like Drew mentioned).

CLTL 2nd Edition, though, allows implementing special forms as macros:

http://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node59.html

and that's what happened to `defun' between Emacs 24.2 and 24.3, when
its implementation moved from C to Elisp. I think it would make sense to
still consider `defun' a special form, despite the implementation change.

>  > I dunno, calling anything that can be used as a car of an evaluatable 
>  > sexp a "function" makes sense in general context.
>
> But there's a reason to avoid that usage where possible.  In Lisp,
> functions are "funcall-able", while special operators and macros are
> not.  This makes functions "first class" objects in a way that special
> operators and macros are not.

Sure, I just meant that the usage of "function" in the introduction
makes enough sense, despite the lack of precision.

> Footnotes: 
> [1]  
> http://www.lispworks.com/documentation/HyperSpec/Body/03_ababa.htm#clspecialops



reply via email to

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