From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: A combination of defmacro, functionp, and quoted lambdas yields different results on consecutive evaluations Date: Mon, 26 Feb 2018 12:13:23 -0500 Message-ID: References: <08190786-14de-a899-f591-a7043c87bebb@gmail.com> <9dbc26f4-e86f-c3df-8193-61a0a3837466@gmail.com> <10414fb8-e09c-a4fa-dcd1-5ccfff10650d@gmail.com> <555f3f1b-d31f-ec12-e460-8b0c20816d45@gmail.com> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1519665096 4602 195.159.176.226 (26 Feb 2018 17:11:36 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 26 Feb 2018 17:11:36 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: emacs-devel@gnu.org To: =?windows-1252?Q?Cl=E9ment?= Pit-Claudel Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Feb 26 18:11:32 2018 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eqMJG-0000lD-0r for ged-emacs-devel@m.gmane.org; Mon, 26 Feb 2018 18:11:30 +0100 Original-Received: from localhost ([::1]:60441 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eqMLI-0006kT-1m for ged-emacs-devel@m.gmane.org; Mon, 26 Feb 2018 12:13:36 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45762) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eqMLB-0006ji-Nb for emacs-devel@gnu.org; Mon, 26 Feb 2018 12:13:30 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eqML7-0004F8-L8 for emacs-devel@gnu.org; Mon, 26 Feb 2018 12:13:29 -0500 Original-Received: from pruche.dit.umontreal.ca ([132.204.246.22]:36623) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eqML7-0004Ew-F4 for emacs-devel@gnu.org; Mon, 26 Feb 2018 12:13:25 -0500 Original-Received: from lechazo.home (lechon.iro.umontreal.ca [132.204.27.242]) by pruche.dit.umontreal.ca (8.14.7/8.14.1) with ESMTP id w1QHDNxJ011801; Mon, 26 Feb 2018 12:13:23 -0500 Original-Received: by lechazo.home (Postfix, from userid 20848) id 640D7685C3; Mon, 26 Feb 2018 12:13:23 -0500 (EST) In-Reply-To: <555f3f1b-d31f-ec12-e460-8b0c20816d45@gmail.com> (=?windows-1252?Q?=22Cl=E9ment?= Pit-Claudel"'s message of "Mon, 26 Feb 2018 12:01:50 -0500") X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 2 Rules triggered EDT_SA_DN_PASS=0, RV6230=0 X-NAI-Spam-Version: 2.3.0.9418 : core <6230> : inlines <6432> : streams <1780105> : uri <2599745> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 132.204.246.22 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:223072 Archived-At: > My user's problem is the following: Flycheck defines a macro that lets > you define a new checker. One of our users wrote something like this: > > (with-eval-after-load 'flycheck > (flycheck-define-checker > =E2=80=A6)) > > This doesn't work. I claim that it should, or that it should be > documented to not work. Do you disagree? I think it is or should be documented, indeed, but not in `with-eval-after-load` since this applies to everything else as well. If you need to use a macro that's in file `foo`, then AFAIK you have 2 options: - (require 'foo), either directly or transitively. - hide your macro call behind a quote so it can't be compiled before `foo` is loaded (regardless of whether you do compile or not irrelevant: the right way to think about it is "what happens when it gets compiled"). > Because of the documentation says that this macro arranges for evaluation= to > be delayed. But macro expansion can take place long before evaluation. E.g. `defun` also delays evaluation of its body. But (defun foo () ... (mmm blabla) ...) (defmacro mmm (...) ...) will suffer from the same problem (tho at least in this particular case, the byte-compiler will notice and emit a warning, IIRC). Stefan