From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.devel Subject: RE: [Emacs-diffs] trunk r117002: Correctly treat progn contents as toplevel forms when byte compiling Date: Tue, 22 Apr 2014 13:41:44 -0700 (PDT) Message-ID: References: <535558EA.7070506@dancol.org> <53559BD2.3000006@dancol.org> <5355D244.2050104@dancol.org> <5355F442.6080606@dancol.org> <5356A56B.4060501@dancol.org> <5356B15B.7020802@dancol.org> <172ea415-25d9-48d8-bc98-8017ff5ff332@default> <5356C1B8.4070007@dancol.org> <532ec4ce-8fbd-4792-b2a5-8c4e0f86b21c@default> <5356CCA9.2000908@dancol.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1398199344 15334 80.91.229.3 (22 Apr 2014 20:42:24 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 22 Apr 2014 20:42:24 +0000 (UTC) Cc: emacs-devel@gnu.org To: Daniel Colascione , Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Apr 22 22:42:17 2014 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1WchWC-0004Qc-NR for ged-emacs-devel@m.gmane.org; Tue, 22 Apr 2014 22:42:16 +0200 Original-Received: from localhost ([::1]:57147 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WchWC-0007iF-88 for ged-emacs-devel@m.gmane.org; Tue, 22 Apr 2014 16:42:16 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45176) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WchW1-0007hc-85 for emacs-devel@gnu.org; Tue, 22 Apr 2014 16:42:13 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WchVs-0002Lt-F1 for emacs-devel@gnu.org; Tue, 22 Apr 2014 16:42:05 -0400 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:46174) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WchVs-0002Lp-8M for emacs-devel@gnu.org; Tue, 22 Apr 2014 16:41:56 -0400 Original-Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s3MKflMF029875 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 22 Apr 2014 20:41:48 GMT Original-Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id s3MKflIH027319 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 22 Apr 2014 20:41:47 GMT Original-Received: from abhmp0019.oracle.com (abhmp0019.oracle.com [141.146.116.25]) by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id s3MKfkCU027301; Tue, 22 Apr 2014 20:41:46 GMT In-Reply-To: <5356CCA9.2000908@dancol.org> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.8 (707110) [OL 12.0.6691.5000 (x86)] X-Source-IP: ucsinet22.oracle.com [156.151.31.94] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] X-Received-From: 141.146.126.69 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 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-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:171593 Archived-At: > >> The SBCL and ECL behavior is what I'd expect from reading the spec, bu= t > >> maybe I misunderstood something. > > > > Hm. What part of the spec do you think gives the impression that > > `defmacro' behavior is defined only at top level? >=20 > defmacro is specced to "define[] name as a macro by associating a macro > function with that name in the global environment".=20 > Like any form, it's supposed to do that when it's evaluated, Yes, anywhere and anywhen it's evaluated, including from a file at any level. And including when invoked from running code. And including `defmacro' forms that are generated and eval'd on the fly. > and forms inside defuns aren't evaluated when they're loaded or > compiled: they're evaluated when the defun is called. So you should > expect a defmacro inside a defun to have no effect unti lthe defun is > called. Agreed, but when the defun is called and the `defmacro' is evaluated, its behavior should be well-defined - it is not just up for grabs or up to the implementation. But I do see now that you allowed for `progn' contexts, at least. I guess you meant any context, like progn, which evaluates the `defmacro' at load or compile time. > Likewise, if a defmacro appears at top level, it should ordinarily be > evaluated only when the file that contains it is loaded, just like any > other toplevel form. So, without special provisions, defmacro should not > be expanded inside forms that happen to be in the same file. >=20 > But this behavior isn't very useful, so as a special case, CL specifies > that "if a defmacro form appears as a top level form, the compiler must > store the macro definition at compile time, so that occurrences of the > macro later on in the file can be expanded correctly. Users must ensure > that the body of the macro can be evaluated at compile time if it is > referenced within the file being compiled." That was precisely the passage I was thinking of, BTW. It does not say anything about `defmacro' inside a defun signaling a compile-time error, as opposed to doing what you write above: "have no effect until the defun is called". A priori, when the defun is called the `defmacro' inside it should be evaluated, defining the macro normally, no? It says clearly that IF you expect the macro to be available to code in the same file at compile time for that file, THEN you must ensure that it gets evaluated at compile time. If not, then not. > It's because of this special case that a normal defmacro, not wrapped in > an eval-when, has any effect on compilation of forms in the same file. A > defmacro inside a defun isn't covered by this special case, so its > behavior should revert to the normal behavior for forms. Which is what? Why isn't it that the embedded `defmacro' would, as you said "have no effect until the defun is called"? > SBCL and ECL implement this model of evaluation. CLISP's behavior > appears to be incorrect here. I don't see that either of those behaviors realizes the exclusive truth here. All I see that passage saying is that you must not expect a `defvar' embedded in a defun to have an effect, at compile time, on subsequent code located in the same file. I don't see that as a call to raise a compile-time error. > The behavior I'm proposing for Emacs is identical to what SBCL and ECL > do. Stefan is proposing that we adopt CLISP behavior. I see. Anyway, I misunderstood your original comment about `defmacro' behavior being undefined if not at top level - sorry. (And I have no special opinion about the question you are deciding. A priori, I prefer that Emacs Lisp be closer to CL, but I have no opinion about this particular issue.)