unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Drew Adams <drew.adams@oracle.com>
To: Philipp Stephani <p.stephani2@gmail.com>
Cc: "47862@debbugs.gnu.org" <47862@debbugs.gnu.org>
Subject: bug#47862: [External] : Re: bug#47862: 26.3; (elisp) `Eval During Compile'
Date: Sun, 18 Apr 2021 15:20:07 +0000	[thread overview]
Message-ID: <SA2PR10MB4474B22E7333BA1B22A920AFF34A9@SA2PR10MB4474.namprd10.prod.outlook.com> (raw)
In-Reply-To: <CAArVCkQHzyNHs6DAApmyDRjiybzFiGQd5JdpOUt1JCEatbJOgw@mail.gmail.com>

> Could we instead redefine "special form" to mean "any form that
> doesn't evaluate its arguments like a function does, no matter whether
> it's implemented in C or as an ELisp macro"? It normally doesn't
> matter for users how such forms are implemented.

No, please don't.  Both macro and special form have
established meanings in Emacs.

And neither necessarily does not evaluate its args.
It's incorrect to give the impression that that's
the case.

What's the case is that neither necessarily evals
its args - any or all of its args, and if it does
evaluate any args it doesn't necessarily eval them
in any particular order.

A macro should be referred to in the doc as a macro.
A special form isn't implemented as a macro, and it
should be referred to in the doc as a special form.

Beyond that, we should not be calling `foo' a macro
in some help (e.g. doc string) and calling it a
special form in other help (e.g. Elisp manual).



  reply	other threads:[~2021-04-18 15:20 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-18  4:09 bug#47862: 26.3; (elisp) `Eval During Compile' Drew Adams
2021-04-18  4:14 ` Drew Adams
2021-04-18  4:24   ` Drew Adams
2021-04-18  8:21 ` Philipp Stephani
2021-04-18 15:20   ` Drew Adams [this message]
2021-05-04  9:30 ` Lars Ingebrigtsen
2021-05-04 11:05   ` Stephen Berman
2021-05-05  8:32     ` Lars Ingebrigtsen

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=SA2PR10MB4474B22E7333BA1B22A920AFF34A9@SA2PR10MB4474.namprd10.prod.outlook.com \
    --to=drew.adams@oracle.com \
    --cc=47862@debbugs.gnu.org \
    --cc=p.stephani2@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).