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 10:22:51 -0700 Message-ID: <5356A56B.4060501@dancol.org> References: <535558EA.7070506@dancol.org> <53559BD2.3000006@dancol.org> <5355D244.2050104@dancol.org> <5355F442.6080606@dancol.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="NsRckK17LKI63iGXFHu9aP3oq2CcesVgA" X-Trace: ger.gmane.org 1398187386 15691 80.91.229.3 (22 Apr 2014 17:23:06 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 22 Apr 2014 17:23:06 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Apr 22 19:23:00 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 1WcePL-0001Dj-HB for ged-emacs-devel@m.gmane.org; Tue, 22 Apr 2014 19:22:59 +0200 Original-Received: from localhost ([::1]:56389 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WcePL-00024E-2X for ged-emacs-devel@m.gmane.org; Tue, 22 Apr 2014 13:22:59 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58016) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WcePH-00023w-2i for emacs-devel@gnu.org; Tue, 22 Apr 2014 13:22:56 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WcePF-0006mR-Pe for emacs-devel@gnu.org; Tue, 22 Apr 2014 13:22:55 -0400 Original-Received: from dancol.org ([2600:3c01::f03c:91ff:fedf:adf3]:46199) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WcePF-0006mN-F6 for emacs-devel@gnu.org; Tue, 22 Apr 2014 13:22:53 -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=41t13p9OYdn6/KcdimkBnpO3nBY4aaOChgStaMSOOp0=; b=M8O4nVHkzwsnqdvLNPfcQDSxMSKs/i6CQykyjWPS8jvT/LQY7UtoozcFCaIqlBqYS2JFDfBjK9+WE9UqUaKhDSTU/Idi6BXbOgkn4JefFEl/4Ti9RiPoLwEq/eDmYJZjpMWh9Dy6BwtzZGHI4Xm4nTEi9JLmYxuKnru9U1YIasQOI1T/uNX1IX0ZkNYB3yFLH24gCnEtnNIzClP2qMO/vV8IdNpxhjMKWxy07eI60AUdSFTgzbN5oZw7D7e8VDevUK2XOKAw4jfGiWJoD8pnBIy+N1z7k3rXDul6TXhQHJTDeOGsgGsj+yjhFutsaQ7zry3ygucP05EFRAZGrIoY8g==; Original-Received: from [2601:8:b200:2b6::2b1] by dancol.org with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1WcePE-0000RA-Go; Tue, 22 Apr 2014 10:22:52 -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:171582 Archived-At: This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --NsRckK17LKI63iGXFHu9aP3oq2CcesVgA Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 04/22/2014 08:06 AM, Stefan Monnier wrote: > And if you insist on doing it this way, you can wrap the cl-defstruct > within an eval-and-compile. >=20 > The problem with relying on CL semantics, is that it means that your > iface-declare will only work at top-level, e.g. not within a `cl-letf' > or a `cl-flet' or ... > a > So while the current semantics bites you, CL's semantics will also bite= > you in other cases. IOW They just try to avoid biting you in a couple > more cases, but they can't avoid the fundamental problem. > > The above example doesn't convince me yet that the convenience of hidin= g > the fundamental problem in those few cases is worth the trouble. > > Maybe to solve this problem right, we'd need to do it in > macroexpand-all: detect a "defmacro" and add the corresponding macro to= > macroexpand-all-environment for the rest of the expansion. Not sure > it'd be worth the trouble, but at least it would fix this "toplevel > special case". That's fine too, provided we handle the toplevel case correctly. Would you accept a change that did that? --NsRckK17LKI63iGXFHu9aP3oq2CcesVgA 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/ iQIcBAEBAgAGBQJTVqVrAAoJEMAaIROpHW7IUaYP/REDESUcreRtNlm9C6HEwZap zMunNgDIOjltMHo80kHk9xRFYqmDEsqU96YqPKV+dVM/wWLMH5oOQYVvRxiyaKLu kcwBE8GtfeqMAbm1upZbKcdui2qAqyDiFP6Y1NdniOv++UncgS76wcqVVEj5acfQ jd74L/4pHuh+CmSGqeI9PhjAGV4D57nApW4HOJfp6xho2G7I9ueEj0phCPUYZg7N HhTXtOHr1YNsBm8pAOBxEDoYtahC9x720V9O9MGH3vfdzTj6kSc9IzqckwGAv/JP HV5B3y+v82LqsI2jSVFjZgCN/rtJ/YZz1HQyeeY1ZmAbnbbUtK04t3jV1X/8R0Uy 7jvQCwBb/P/moOtSVqQq4s/o5kyO7RqXBA9UIvEnIWzGruvawLWlsnJnLIBa3E4x FTt6ycTxdkAxVxLwuwAomz7nybTST4BWBvi8YzuBZaNOJGDJIh5m5yAJVLcl6rnT di5h1hlbuW92oIqsW9aJZuYwnjL4XX9qUYGiPCE9wThYh8AoPK5JIHLv4NZMVmXD rBRbKnQvhOnLczXbs1I2W8sNJIz8UOR9zbLEb+BMs6mOWU/ylMqkpwPGveGY/J+o umg/vEdM0L6qjEPZbsX0Vv47h2uCSHhnNJfSm2ATNl1xpOpHbfjq+1zDnrPPGn+E HzVYJF87KG6Sq/Dkb2OY =YbNc -----END PGP SIGNATURE----- --NsRckK17LKI63iGXFHu9aP3oq2CcesVgA--