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:31:45 -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> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1519666230 17414 195.159.176.226 (26 Feb 2018 17:30:30 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 26 Feb 2018 17:30:30 +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:30:26 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 1eqMbZ-0003z9-UN for ged-emacs-devel@m.gmane.org; Mon, 26 Feb 2018 18:30:26 +0100 Original-Received: from localhost ([::1]:60548 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eqMdb-0000DM-AW for ged-emacs-devel@m.gmane.org; Mon, 26 Feb 2018 12:32:31 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:51248) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eqMcy-0000DA-9Q for emacs-devel@gnu.org; Mon, 26 Feb 2018 12:31:53 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eqMcv-0007P6-0u for emacs-devel@gnu.org; Mon, 26 Feb 2018 12:31:52 -0500 Original-Received: from chene.dit.umontreal.ca ([132.204.246.20]:59762) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eqMcu-0007Oj-Pu for emacs-devel@gnu.org; Mon, 26 Feb 2018 12:31:48 -0500 Original-Received: from lechazo.home (lechon.iro.umontreal.ca [132.204.27.242]) by chene.dit.umontreal.ca (8.14.7/8.14.1) with ESMTP id w1QHVjFW012323; Mon, 26 Feb 2018 12:31:45 -0500 Original-Received: by lechazo.home (Postfix, from userid 20848) id B993E685C3; Mon, 26 Feb 2018 12:31:45 -0500 (EST) In-Reply-To: (=?windows-1252?Q?=22Cl=E9ment?= Pit-Claudel"'s message of "Mon, 26 Feb 2018 12:08:25 -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 <6434> : streams <1780106> : uri <2599755> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 132.204.246.20 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:223075 Archived-At: > Is that actually a usable criterion? Any macro can quote or unquote its > argument, right? Everything can happen, indeed. But usually a macro which takes a code argument and puts it within a quote is perceived as a problem: e.g. it tends to very quickly annoy its users because they can't refer to lexically-scoped arguments any more. Admittedly, for with-eval-after-load this is not very problematic because it's unusual to have with-eval-after-load elsewhere than at top-level, so making code like: (let ((x 1)) (with-eval-after-load FOO (message "%S" x))) work correctly is not nearly as important as it is for many other macros. Code looks a lot like data, but for reasons of lexical scoping, *variables* are quite different from symbols, yet we don't have any data to represent *variables* (so we use symbols instead). > For example, the problem that I described about with-eval-after-load > also happens with eval-after-load, yet the argument to that is quoted. [ I was wondering when someone would notice. ] Indeed, when I introduced `with-eval-after-load` and I also changed `eval-after-load` by adding a compiler macro which turns (eval-after-load FOO 'BAR) into (eval-after-load FOO `(,(lambda () BAR))) so that BAR can be properly eagerly macro-expanded, so the byte-compiler can look at BAR and emit warnings about it, and also so that BAR will be interpreted using lexical-binding if the containing file uses lexical-binding. Here's the kind of thing I had in mind (can't think of any concrete example for it, tho, the motivation came from such cases in defadvice and interactive forms instead, which had the same problem is keeping code quoted thus preventing compilation and eager macroexpansion): (eval-when-compile (require 'cl)) (eval-after-load FOO '(flet ...)) There are a few other places where we "undo" a quote, as in (mapcar '(lambda ...) ...) These were all done because it seemed to be beneficial more often than it is harmful. I must admit that I wasn't 100% sure that "unquoting" its arg was "more often beneficial", tho the fact that I haven't heard anyone even mention this until now seems to argue that even tho it's maybe not "more often beneficial" at least not often harmful. Stefan