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 14:05:27 -0700 Message-ID: <5356D997.2030006@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> <5356CCA9.2000908@dancol.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="122XksfEquhaBPHreVwEO7Ece3Aaq72g3" X-Trace: ger.gmane.org 1398200753 3590 80.91.229.3 (22 Apr 2014 21:05:53 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 22 Apr 2014 21:05:53 +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 23:05:47 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 1Wchsw-0000MM-DG for ged-emacs-devel@m.gmane.org; Tue, 22 Apr 2014 23:05:46 +0200 Original-Received: from localhost ([::1]:57201 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wchsv-0007yC-UK for ged-emacs-devel@m.gmane.org; Tue, 22 Apr 2014 17:05:45 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49848) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wchsp-0007xI-PC for emacs-devel@gnu.org; Tue, 22 Apr 2014 17:05:41 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Wchso-0000Tc-JB for emacs-devel@gnu.org; Tue, 22 Apr 2014 17:05:39 -0400 Original-Received: from dancol.org ([2600:3c01::f03c:91ff:fedf:adf3]:47282) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wchsn-0000TT-T2 for emacs-devel@gnu.org; Tue, 22 Apr 2014 17:05:38 -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=5uX4k07dHE8zmKqyo47Lg2RmSMXHiszf0Vr91ZvCbww=; b=IrCXepvlDv1nZaWg8uL7S5g45xPUaUxZQsWd2vFG+UfxMZb7J0CdTSsNE3GaQkttluVrvIOFdTpoMntljmdCcetTo2vb5JIq09Lr/5LtsJMmX3gWboj9MIZoTMGV5NVSsxPbQGXWXoGWKG5+2loXk7VgO8FUy2TUAmEirEeSXi78gHzYIPPY12dOT7Vxe5r3jEtU+7Y9r069L9M0PUPpP6GvQPPIAnzR55bVdC5b8L9Of3+lAsdyWipCbfLB+f6gMgUdrjTKaCkNbmAGVP3zDXkT8Lpm+DymxOLjfaIFJKelHxU+iUPdllauMVLxWV1wvUHz40DaErVKJD01FCRBkg==; 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 1Wchsj-0001Sr-TL; Tue, 22 Apr 2014 14:05:33 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 In-Reply-To: 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:171594 Archived-At: This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --122XksfEquhaBPHreVwEO7Ece3Aaq72g3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 04/22/2014 01:41 PM, Drew Adams wrote: >>>> The SBCL and ECL behavior is what I'd expect from reading the spec, = but >>>> 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? >> >> defmacro is specced to "define[] name as a macro by associating a macr= o >> function with that name in the global environment".=20 >=20 >> Like any form, it's supposed to do that when it's evaluated, >=20 > 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. That goes without saying. > 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. >=20 > 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? Neither did I. I was imprecise: the code I mentioned compiles without error. It signals an error at runtime because there is no function called `bar'. The function is trying to call `bar' because the macro `bar' wasn't expanded during compilation. > 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. >=20 >> 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. >=20 > Which is what? Why isn't it that the embedded `defmacro' would, as you= > said "have no effect until the defun is called"? "No effect until the defun is called" is the correct behavior. >> SBCL and ECL implement this model of evaluation. CLISP's behavior >> appears to be incorrect here. >=20 > 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. There is no compile-time error; sorry for the misunderstanding. --122XksfEquhaBPHreVwEO7Ece3Aaq72g3 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/ iQIcBAEBAgAGBQJTVtmXAAoJEMAaIROpHW7IBIQP/AwERPpqQYqDVd8Hqhnj/5er wNaBSIE16npgZr8gKtVRxxgEZudu+ZMRVwPk6BpUuB481u5USBI1Wp3w62ANykXY 5Yr5CX47XqY4gBEVFRTbCea0Fq4p4l3ixkVgX3iMDTb1mjsJ0Ga8ZkCbz4nzzEH9 OWeOEDwCQFgpjetNnGI4ONgpRa41sNRdjV7JMrJi00GYXaUG+HUwyU5AJ31Nnl82 nLP3s3CFAcUUqn1qQbla1svWs2YGHp7xqI+vcdl6ioTUn228h8mGZzw0Gz1IMUix jcK+dnB6xgDnLBwGTaulkMjJ7JQutL+DYVSSOE1nla73YwhKd14bVwPXhf8gOw39 mlypEVW9Vo/wsfCbBu7fFmoZtTRuI6an/1dqvo21+6uS8Fe7WdMCHeOBeYdorcVo KvBphOEg50lt+l+8TMmFy/BIY8bmzigGs/Q9jbIVIX61fLo0SVpfSynorqTdu8l+ kFCU09+AlhiLlhvogfXIn2FcSsgaeawOfrk9TnQcEQNibOb5du7mhWrsn2gYAJn0 J2NtbhduGGByWdwVfbWryV88wTr/Lme6DFapEI0XSIHq/22Jk9+0hC1AF8VeAToR jk0xVaf36tdvj3eUKGatv3Cz7BTDOkNrQ+hdXmvlGsY8HBuu0mYNDuDdd8O+lY82 VinkBVIKUxK17bdquBPq =RSlR -----END PGP SIGNATURE----- --122XksfEquhaBPHreVwEO7Ece3Aaq72g3--