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 than special forms. (Bug#13853)

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 than special forms. (Bug#13853)

[Leo Liu]

On 2013-04-21 20:01 +0800, Xue Fuqiao wrote:
>   * 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)

"special form" is a better term than "macro". It signals the reader that
the form has special evaluation rule. How the special form is
implemented is details readers need not care about. Please don't change
a clearly written text to worse.

Leo

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 than special forms. (Bug#13853)

[xfq]

On Sun, Apr 21, 2013 at 8:39 PM, Leo Liu <sdl.web@gmail.com> wrote:
> On 2013-04-21 20:01 +0800, Xue Fuqiao wrote:
>>   * 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)
>
> "special form" is a better term than "macro". It signals the reader that
> the form has special evaluation rule. How the special form is
> implemented is details readers need not care about. Please don't change
> a clearly written text to worse.

Thanks for your attention.  A "special form" is a primitive function,
and a "macro" is a construct defined in Lisp.  Both of them are
mentioned in this manual (or tutorial):

(info "(eintr) Lisp macro")
(info "(eintr) Complications")

I think cross reference(s) to the `Lisp macro' node is a better than
revert this change.

--
Best regards, Xue Fuqiao.
http://www.gnu.org/software/emacs/

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 than special forms. (Bug#13853)

[Dmitry Gutov]

xfq <xfq.free@gmail.com> writes:

> On Sun, Apr 21, 2013 at 8:39 PM, Leo Liu <sdl.web@gmail.com> wrote:
>> On 2013-04-21 20:01 +0800, Xue Fuqiao wrote:
>>>   * 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)
>>
>> "special form" is a better term than "macro". It signals the reader that
>> the form has special evaluation rule. How the special form is
>> implemented is details readers need not care about. Please don't change
>> a clearly written text to worse.
>
> Thanks for your attention.  A "special form" is a primitive function,
> and a "macro" is a construct defined in Lisp.  Both of them are
> mentioned in this manual (or tutorial):
>
> (info "(eintr) Lisp macro")
> (info "(eintr) Complications")

Indeed, there is some confusion in terminology there.

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

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,
and this opinion is supported by this sentence, removed in r112347:

  Because @code{defun} does not evaluate its arguments in the usual way,
  it is called a @dfn{special form}.

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

--Dmitry

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]

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

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)

[Dmitry Gutov]

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

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

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.

http://www.lispworks.com/documentation/HyperSpec/Body/03_ababa.htm

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

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.

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)

[Stephen J. Turnbull]

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

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


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

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)

[Dmitry Gutov]

"Stephen J. Turnbull" <stephen@xemacs.org> 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

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]

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

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)

[Stephen J. Turnbull]

Drew Adams writes:

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

Surely not!

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 ratherthanspecial forms. (Bug#13853)

[Drew Adams]

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

Ouch!  mea culpa.

I need to stop checking things with Emacs prior to Emacs 22.  Or at least check
both old and new, to see that yes, this was changed in Emacs 22.

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 ratherthanspecial forms. (Bug#13853)

[Stephen J. Turnbull]

Drew Adams writes:
 > >  > By `functionp':
 > >  > (defmacro foo (a) 42)
 > >  > (functionp 'foo) => t
 > > 
 > > Surely not!
 > 
 > Ouch!  mea culpa.
 > 
 > I need to stop checking things with Emacs prior to Emacs 22.

If it returns t in any Emacs in which macros are not funcall'able,
functionp is buggy (unless the docstring was also changed, but that
seems unlikely).  A better test is whether `(funcall 'foo nil)'
errors.

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 macrosratherthanspecial forms. (Bug#13853)

[Drew Adams]

> > (functionp 'foo) => t
> 
> If it returns t in any Emacs in which macros are not funcall'able,
> functionp is buggy (unless the docstring was also changed, but that
> seems unlikely).  A better test is whether `(funcall 'foo nil)'
> errors.

Yes, not to worry.  It raises an error in Emacs 21 and 20:

Debugger entered--Lisp error:
  (invalid-function (macro lambda (a) 42))
  foo(nil)
  funcall(foo nil)

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)

[Dmitry Gutov]

"Drew Adams" <drew.adams@oracle.com> writes:

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

Looks like I misunderstood that part of the text (see my other reply),
"special operators" are cars of "special forms". IIU it correctly now,
"special form" is a "special operator" application, together with the
arguments:

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

With that terminilogy, "special operator" in CL = "special form" in Elisp.

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

That's the core of my objection, actually. It doesn't seem to me that
the way the special form is implemented is particularly relevant at that
point of the manual.
Providing too much details will mostly result in more situations when
the manual has to be corrected. Like in this case, when `defun'
implementation moved from C to Elisp in Emacs 24.3.

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

True.

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 than special forms. (Bug#13853)

[Glenn Morris]

The problem I saw with these changes, and the reason I did not fix it at
the time it was reported, is that previously "special form" was defined
(in a simple way using only a couple of sentences) before it was used to
refer to any particular function. Now the term "macro" is used well
before it is defined. So the manual no longer makes sense when read in
order, which matters for an introduction IMO. It needs more work that
just replacing "special form" by "macro" in a few places.

Also, the menu is now inconsistent:

* defun::                        The @code{defun} special form.

etc

> -(Another special form, @code{defcustom}, is designed for variables
> -that people customize.  It has more features than @code{defvar}.
> -(@xref{defcustom, , Setting Variables with @code{defcustom}}.)

Why was this removed? It could have been simply changed to "Another
function,... ". The reference to defcustom is the important thing, not
the details of whether it is a special form or macro.


PS Please keep commit log lines to ~ 80 chars in length.
The first line should be a summary that can stand alone.
Eg "Minor emacs-lisp-intro updates related to special forms"

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 than special forms. (Bug#13853)

[xfq]

On Mon, Apr 22, 2013 at 2:07 AM, Glenn Morris <rgm@gnu.org> wrote:
>
> The problem I saw with these changes, and the reason I did not fix it at
> the time it was reported, is that previously "special form" was defined
> (in a simple way using only a couple of sentences) before it was used to
> refer to any particular function. Now the term "macro" is used well
> before it is defined. So the manual no longer makes sense when read in
> order, which matters for an introduction IMO. It needs more work that
> just replacing "special form" by "macro" in a few places.

Maybe we can add this sentence to (info "(eintr) defun") or (info
"(eintr) Complications"), then add a cross reference to (info "(eintr)
Lisp macro"):

  "Macro" is a construct defined in Lisp, which differs from a function in
  that it translates a Lisp expression into another expression which is to
  be evaluated instead of the original expression.

> Also, the menu is now inconsistent:
>
> * defun::                        The @code{defun} special form.
>
> etc

Sorry, I forgot it.

>> -(Another special form, @code{defcustom}, is designed for variables
>> -that people customize.  It has more features than @code{defvar}.
>> -(@xref{defcustom, , Setting Variables with @code{defcustom}}.)
>
> Why was this removed? It could have been simply changed to "Another
> function,... ". The reference to defcustom is the important thing, not
> the details of whether it is a special form or macro.

Maybe "another macro"?

I think there are not too many complications in this
introduction/tutorial.  Lambda expression is in the appendix, and
closure and byte-code function are not mentioned.  Since macros in
explained in the main body of this tutorial, I don't think it is more
clear to lie.

> PS Please keep commit log lines to ~ 80 chars in length.
> The first line should be a summary that can stand alone.
> Eg "Minor emacs-lisp-intro updates related to special forms"

Thanks, I will do it the next time.  (Is there anyway to amend this
commit log?)

--
Best regards, Xue Fuqiao.
http://www.gnu.org/software/emacs/

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 than special forms. (Bug#13853)

[Glenn Morris]

> Maybe we can add this sentence to (info "(eintr) defun") or (info
> "(eintr) Complications"), then add a cross reference to (info "(eintr)
> Lisp macro"):
>
>   "Macro" is a construct defined in Lisp, which differs from a function in
>   that it translates a Lisp expression into another expression which is to
>   be evaluated instead of the original expression.

I think a few sentences in "Complications" after the bit about special
forms with a link to the "Lisp macro" section of eintr is indeed all
that is needed. Personally I would say something about it acting like a
function for our [ie, the elisp-intro's] purposes.

>>> -(Another special form, @code{defcustom}, is designed for variables
>>> -that people customize.  It has more features than @code{defvar}.
>>> -(@xref{defcustom, , Setting Variables with @code{defcustom}}.)
>>
>> Why was this removed? It could have been simply changed to "Another
>> function,... ". The reference to defcustom is the important thing, not
>> the details of whether it is a special form or macro.
>
> Maybe "another macro"?

For the purposes of the elisp-intro, I have no problem saying a macro is
a function. You call it with arguments and it does stuff. "Another
macro" is wrong because defvar is not a macro. If you want to say macro
rather than function, you need to rewored it a bit more. Eg:

  There is a related macro, @code{defcustom}, designed for variables
  that people customize.  It has more features than @code{defvar}.
  (@xref{defcustom, , Setting Variables with @code{defcustom}}.)

> Thanks, I will do it the next time.  (Is there anyway to amend this
> commit log?)

No, it's immutable. But no big deal, so don't worry about it.

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 than special forms. (Bug#13853)

[Xue Fuqiao]

On Tue, Apr 23, 2013 at 1:02 AM, Glenn Morris <rgm@gnu.org> wrote:

>> Maybe we can add this sentence to (info "(eintr) defun") or (info
>> "(eintr) Complications"), then add a cross reference to (info "(eintr)
>> Lisp macro"):
>>
>>   "Macro" is a construct defined in Lisp, which differs from a function in
>>   that it translates a Lisp expression into another expression which is to
>>   be evaluated instead of the original expression.
>
> I think a few sentences in "Complications" after the bit about special
> forms with a link to the "Lisp macro" section of eintr is indeed all
> that is needed. Personally I would say something about it acting like a
> function for our [ie, the elisp-intro's] purposes.
>
>>>> -(Another special form, @code{defcustom}, is designed for variables
>>>> -that people customize.  It has more features than @code{defvar}.
>>>> -(@xref{defcustom, , Setting Variables with @code{defcustom}}.)
>>>
>>> Why was this removed? It could have been simply changed to "Another
>>> function,... ". The reference to defcustom is the important thing, not
>>> the details of whether it is a special form or macro.
>>
>> Maybe "another macro"?
>
> For the purposes of the elisp-intro, I have no problem saying a macro is
> a function. You call it with arguments and it does stuff. "Another
> macro" is wrong because defvar is not a macro. If you want to say macro
> rather than function, you need to rewored it a bit more. Eg:
>
>   There is a related macro, @code{defcustom}, designed for variables
>   that people customize.  It has more features than @code{defvar}.
>   (@xref{defcustom, , Setting Variables with @code{defcustom}}.)

Done as r112355, thanks.

--
Best regards, Xue Fuqiao.
http://www.gnu.org/software/emacs/

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 than special forms. (Bug#13853)

[Glenn Morris]

You missed these (possibly others with line-breaks):

   3062:* defun::                        The @code{defun} special form.
   3703:@xref{defun, , The @code{defun} Special Form}.)
  19459:@ref{defun, , The @code{defun} Special Form}.)
  20979:(@xref{defun, ,  The @code{defun} Special Form}.)

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 than special forms. (Bug#13853)

[Xue Fuqiao]

On Wed, Apr 24, 2013 at 12:42 AM, Glenn Morris <rgm@gnu.org> wrote:

> You missed these (possibly others with line-breaks):
>
>    3062:* defun::                        The @code{defun} special form.
>    3703:@xref{defun, , The @code{defun} Special Form}.)
>   19459:@ref{defun, , The @code{defun} Special Form}.)
>   20979:(@xref{defun, ,  The @code{defun} Special Form}.)

Done,thanks.

--
Best regards, Xue Fuqiao.
http://www.gnu.org/software/emacs/

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 than special forms. (Bug#13853)

[Leo Liu]

On 2013-04-22 02:07 +0800, Glenn Morris wrote:
> The problem I saw with these changes, and the reason I did not fix it
> at the time it was reported.

Exactly.

Doc tweaks can easily turn into bikeshedding. I think a general rule
(for all occasional committers) is to fix obvious errors and discuss
uncertain items before jumping the gun.

This commit is a step backwards.

Leo

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 than special forms. (Bug#13853)

[xfq]

On Mon, Apr 22, 2013 at 11:17 AM, Leo Liu <sdl.web@gmail.com> wrote:
> On 2013-04-22 02:07 +0800, Glenn Morris wrote:
>> The problem I saw with these changes, and the reason I did not fix it
>> at the time it was reported.
>
> Exactly.
>
> Doc tweaks can easily turn into bikeshedding. I think a general rule
> (for all occasional committers) is to fix obvious errors and discuss
> uncertain items before jumping the gun.

Agreed.  I plan to fix all bugs I submitted, and I classified them to
obvious errors (and easy to fix), to-be-discussed, and hard-to-fix bugs.
I considered this bug as an obvious error, maybe I was wrong.

> This commit is a step backwards.

Is this change appropriate:

http://lists.gnu.org/archive/html/emacs-devel/2013-04/msg00591.html

?

--
Best regards, Xue Fuqiao.
http://www.gnu.org/software/emacs/

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 than special forms. (Bug#13853)

[Leo Liu]

On 2013-04-22 18:31 +0800, xfq wrote:
> Is this change appropriate:

I think not.

Whether a special form is implemented in c or lisp macro is
implementation details. I think it is best to revert your change and fix
the one sentence about "special form" instead.

Leo

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 than special forms. (Bug#13853)

[Dmitry Gutov]

On 22.04.2013 18:11, Leo Liu wrote:
> On 2013-04-22 18:31 +0800, xfq wrote:
>> Is this change appropriate:
>
> I think not.
>
> Whether a special form is implemented in c or lisp macro is
> implementation details. I think it is best to revert your change and fix
> the one sentence about "special form" instead.

Which sentence? Every hunk in that changeset contains the words "special 
form".

Most of the discussion here had to do with whether any Elisp macro can 
be called a special form. Apparently not:

ELISP> (special-form-p 'let)
t
ELISP> (special-form-p 'defun)
nil

--Dmitry

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 than special forms. (Bug#13853)

[Leo Liu]

On 2013-04-22 22:19 +0800, Dmitry Gutov wrote:
> Which sentence? Every hunk in that changeset contains the words
> "special form".
>
> Most of the discussion here had to do with whether any Elisp macro can
> be called a special form. Apparently not:
>
> ELISP> (special-form-p 'let)
> t
> ELISP> (special-form-p 'defun)
> nil

Don't know what has changed in trunk though since I can only use the
latest stable release. Anyway it seems concepts have been conflated.

Leo

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 than special forms. (Bug#13853)

[Stefan Monnier]

> "special form" is a better term than "macro".  It signals the reader that
> the form has special evaluation rule.  How the special form is
> implemented is details readers need not care about.  Please don't change
> a clearly written text to worse.

Hmm... there's a tension here: the meaning of "special form" in Lisp
excludes macros, so it is formally incorrect to use special form for
"defun" nowadays.  So, macro calls are "forms that are special" but are
not "special forms".


        Stefan