From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Daniel Colascione 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:10:17 -0700 Message-ID: <5356CCA9.2000908@dancol.org> 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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="pFwWcfx21O0FBpbLdrSb0TpwW05CFNObr" X-Trace: ger.gmane.org 1398197446 16390 80.91.229.3 (22 Apr 2014 20:10:46 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 22 Apr 2014 20:10:46 +0000 (UTC) Cc: emacs-devel@gnu.org To: Drew Adams , Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Apr 22 22:10:40 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 1Wch1b-0000k4-MD for ged-emacs-devel@m.gmane.org; Tue, 22 Apr 2014 22:10:39 +0200 Original-Received: from localhost ([::1]:57032 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wch1a-0000g2-SB for ged-emacs-devel@m.gmane.org; Tue, 22 Apr 2014 16:10:38 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38532) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wch1U-0000eP-HX for emacs-devel@gnu.org; Tue, 22 Apr 2014 16:10:33 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Wch1O-0001GJ-Al for emacs-devel@gnu.org; Tue, 22 Apr 2014 16:10:32 -0400 Original-Received: from dancol.org ([2600:3c01::f03c:91ff:fedf:adf3]:47002) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wch1N-0001GB-LY for emacs-devel@gnu.org; Tue, 22 Apr 2014 16:10:26 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=DdwSvn4qr9mZuu1kfEHAk+jnhCJ7TEVySF2VY0ytvEQ=; b=BSPYGAnwoqr6PkyCfHIxH7ISrPmbtyYueCvW71XdDmCTNus9ysEo6p02/DLV1IWMgtnYOImDufRzeFnEF/GUVv7OOTHj7nmHRLTcG4L4dTL4FzyWmWwwXqZNl/Fhrj+MbcF+hf40cclF1jmgE3EdH/k9kDskHJ1tJane7218jNTgeo3YuyqN2eMTrehL5Re1j4sn5lVIx3rm1ccays8XBCTPGflHA6XcatVUp4jQ5Aw1FJs98Y+9oyltLS/QPrh2zTyvKjkCw8iLYJc32WXJQEGIUUGcMIzRCxOr8ACQexZy6JPdFIE7gapManNt6vQAR6xuwQt0Fklngi+yUDMkDA==; Original-Received: from [2620:10d:c083:1004:2b5:6dff:fe00:f9a6] by dancol.org with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1Wch1M-0001Dw-3a; Tue, 22 Apr 2014 13:10:24 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 In-Reply-To: <532ec4ce-8fbd-4792-b2a5-8c4e0f86b21c@default> X-Enigmail-Version: 1.6 X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2600:3c01::f03c:91ff:fedf:adf3 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:171592 Archived-At: This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --pFwWcfx21O0FBpbLdrSb0TpwW05CFNObr Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 04/22/2014 12:59 PM, Drew Adams wrote: >> The SBCL and ECL behavior is what I'd expect from reading the spec, bu= t >> maybe I misunderstood something. >=20 > Hm. What part of the spec do you think gives the impression that > `defmacro' behavior is defined only at top level? defmacro is specced to "define[] name as a macro by associating a macro function with that name in the global environment". Like any form, it's supposed to do that when it's evaluated, 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. 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. 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." 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. SBCL and ECL implement this model of evaluation. CLISP's behavior appears to be incorrect here. The behavior I'm proposing for Emacs is identical to what SBCL and ECL do. Stefan is proposing that we adopt CLISP behavior. --pFwWcfx21O0FBpbLdrSb0TpwW05CFNObr Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTVsypAAoJEMAaIROpHW7Ix1EP/0rOM42nEbCBtqTD8DYEBTsf hiUncUF/nLJGeouVujzv+gaGt1Jyq0vhyJI62bDQRiavheJfPrh21YacUGN/28DH cSkNJvWCJ1BWXfhaw1WQd6aEA2cqtWF6Km3gdYLYb9G0CsnBiGkRo9SJalFQViqt DenOpr3yx3qUGlhmyPGvBNUhjNo/39JokMaHyzrfeFsTe5JgFgxso6mgSLDGkjAm urefvvcchZEzrkhqZZCKM3qXmJ/BiPgmniT7dSuHoeMcJNkE/9Ie7wwShBhcmq2u Vnq++RW8omUKl+8YJ3imCriHlNWEhUmLxhlpva95No2YnuNzzeaVhneitixI8aYY mJQK0+L5KG0EtZtr6nOJvP5jCDmoJ4sWHf9pnwMyah8hljyngkzqx21UOcqNEHW8 crUiQEuhae/9ruRtqRYGfJeGrGvcNuC/2UqoJydADb06qjsGVYUFvsrJVb33Ftho USvpBg8vTFkgtC/IUm4dU5iW/I/exhuHS0BnuINdmUkTnArvRGi9Lloto3h8HhtT 74HIt8uwADq1enfMiW0Wl5+AElERNPszW3VNP+mgN0QZAM0ajMWQWC+V/O4Uge6f M4eKv5luqpEdGD5qCb4X8zlXv/SE97YGKWK8xd6BAV7Wp+bToc2eCyoW0Caq7FFM uPm73NIHsYJlEXfhHTzt =jgsN -----END PGP SIGNATURE----- --pFwWcfx21O0FBpbLdrSb0TpwW05CFNObr--