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: Mon, 21 Apr 2014 15:29:38 -0700 Message-ID: <53559BD2.3000006@dancol.org> References: <535558EA.7070506@dancol.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="m2qnsw5a7BANJuTJkxceIgPWmGmepPCbB" X-Trace: ger.gmane.org 1398119401 1242 80.91.229.3 (21 Apr 2014 22:30:01 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 21 Apr 2014 22:30:01 +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 00:29:55 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 1WcMin-0002oY-Jg for ged-emacs-devel@m.gmane.org; Tue, 22 Apr 2014 00:29:53 +0200 Original-Received: from localhost ([::1]:51819 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WcMin-0004nJ-6H for ged-emacs-devel@m.gmane.org; Mon, 21 Apr 2014 18:29:53 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39104) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WcMik-0004mU-9y for emacs-devel@gnu.org; Mon, 21 Apr 2014 18:29:51 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WcMif-0000ys-JE for emacs-devel@gnu.org; Mon, 21 Apr 2014 18:29:50 -0400 Original-Received: from dancol.org ([2600:3c01::f03c:91ff:fedf:adf3]:41128) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WcMif-0000yo-Ai for emacs-devel@gnu.org; Mon, 21 Apr 2014 18:29:45 -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=GlHt3JL8x7y0Wy9ecOxeYNle8AWnCKwOKELTePSlRV0=; b=AxHErOQ/0dxE433wTSWXpnfaCyXJljFOyffCaLLNjYudBbkgAajG71i8nOlae+Q10vzZ7sCvPjRFtKVmTtXHybOucMbsj+ww5yMMIwUoEcUhLp5pwoaHvW84mtx8XQ/ONzunYcy+tGxVSdH/jaQPhg4fxrXxFOIeKce37YfMI5WrQjxYHGBcXe0bbAo5wxrbrrqk80+zc06pEfsFQ8S8UKis27mXHcu6VLv/VwVAf0EpKirCemyB2dqnuCAdnY6Y4GjvAbiXLLVAjcxTDZVY0ld+pXFTN3rz0BI5jWEapkBEqPFyzrkhPlYyLsRVNNQc2Yp8uEbFdN2DEWNaT03TJA==; Original-Received: from [2620:10d:c083:1003:863a:4bff:fec8:e538] by dancol.org with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1WcMie-0004Jp-RV; Mon, 21 Apr 2014 15:29:44 -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:171552 Archived-At: This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --m2qnsw5a7BANJuTJkxceIgPWmGmepPCbB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 04/21/2014 03:09 PM, Stefan Monnier wrote: >>>> Correctly treat progn contents as toplevel forms when byte compiling= >>> Your commit messages should be copies of the ChangeLog entry. >>> Could you describe the case(s) that this fixes? >> See the testcases. Generally speaking, this change fixes situations >> where the byte-compiler miscompiles code that contains (or generates) >> top-level progns that define macros, then use them. >=20 > Can you show an example of a macro that does that? Any macro that expands to something like this: (progn (defmacro abc (arg) 1) (defun def () (abc 2))) Some of the iface stuff I was working on used this functionality. The comments in bytecomp.el suggest that EIEIO has similar stuff. In any case, it's a reasonable thing to want to do, so we should support it. >>>> + ;; Macroexpand (not macroexpand-all!) >>> That could be a problem. >> Why? We macroexpand-all forms later when we actually compile or eval t= hem. >=20 > Not sure why, exactly. It just feels like it could be a problem. > Usually, we assume it's safe to use macroexpand-all, and it's not 100% > crystal clear why we could be sure that macroexpand-all won't be used. We only want to expand the top-level macro to see whether it expands into a progn. If it does, we treat each form in the progn as its own top-level form, recursively. If we called macroexpand-all, we'd expand the subforms too soon, before we'd compiled defmacro forms that might be inside the progn body. >> Unless there's a good reason to depart from CL, we should follow CL's >> approach to things. CL in a good sane default, and in this case, CL >> specifies exactly the right behavior. >=20 > Yes. But Elisp's design constraints, especially w.r.t macro expansion,= > are slightly different, partly for historical reasons, partly for > technical reasons. It might not be relevant here, but I just want to > make double sure. It's not relevant here. I also still want to make those macro-expansion changes I proposed last year. --m2qnsw5a7BANJuTJkxceIgPWmGmepPCbB 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/ iQIcBAEBAgAGBQJTVZvSAAoJEMAaIROpHW7I3zMQAKVsZ+yD0886oPTfHwBNM9eA vC9QvFrB4mwoNb4eiyLGlB2QXlDAUNXfmG1FPMMfMv1OtOqIvZIaVmDFnx75CUgs 7cvraL9YORinuZeaUBrYZkFBICn6Y9BXqi0iWhAS53DlNUpzqWekf7FBHkZrCFkd VSO4vveEReHTcYrRDvNCwsuRwJxtF64pSJbFA1fP339tkY6wj20UEJueiDJNge+S sSr8kAURyi/Nddtb/Xuzw9mEAhaw56Ca+sMeKE61YWNtrkrTQoRBs2WVV5mhJvsM EU2mOGJ4+Cpxohvlk8rBhO+BWSAr33m67xCc8t0gruKuthIhhrfa+wxGo4oI9ATJ qH52/nhHSDq0/5H91Aq3KCv0xgZW8K9QTKcz6bzMet6meWARqWu7h44iNeALLl8I hhjVdJzavS3bgwqqKHEgl7LhBP+ltM7Cuchzuuy+CCqIWJ8wSlJuCPGCMfQBH1DO CHG7i4W1Z4h9dDq1EtL/WeaoA1m5ZYkJAKUs3XQz+wfqMTVQPOrQj5EHxOd4ymfD yH1kHD4yLDllMf91tBGrLUfHUM0Au1OLEktfXdfF7Df/3snEPL4Iw5FFHUwlvbsD 1qMzn+AOcbw9Oq0H7g7oum/akL/i5Vr0COM1DQIvHFAwPk5r/oM+qThAU54r8GB3 KesPtpMr6ZTT1ZINAdU3 =boxl -----END PGP SIGNATURE----- --m2qnsw5a7BANJuTJkxceIgPWmGmepPCbB--