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 12:08:46 -0700 Message-ID: <5356BE3E.6040209@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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="w2EPWWkWXxeqAwsERRjGjNW1Lwoi7Tkgb" X-Trace: ger.gmane.org 1398193741 22290 80.91.229.3 (22 Apr 2014 19:09:01 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 22 Apr 2014 19:09: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 21:08:54 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 1Wcg3q-0004Y8-EY for ged-emacs-devel@m.gmane.org; Tue, 22 Apr 2014 21:08:54 +0200 Original-Received: from localhost ([::1]:56779 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wcg3p-0003Sl-Px for ged-emacs-devel@m.gmane.org; Tue, 22 Apr 2014 15:08:53 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52337) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wcg3m-0003Q5-Oj for emacs-devel@gnu.org; Tue, 22 Apr 2014 15:08:51 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Wcg3l-0007hg-Gf for emacs-devel@gnu.org; Tue, 22 Apr 2014 15:08:50 -0400 Original-Received: from dancol.org ([2600:3c01::f03c:91ff:fedf:adf3]:46714) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wcg3l-0007hY-4E for emacs-devel@gnu.org; Tue, 22 Apr 2014 15:08:49 -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=8gtyneowJiHf9faz4lcl2I+2YNup9h5EhwI5LUPtkX8=; b=gi9Ws/dCDFrdmDnkwl5fppA8jpkULoU1fRey0QmDHiVAFzhRvfFgrgx0ChUtCCmsEc2zfPE66a2CUayl3vzcGpx68jYyMHXfegJzR3zhjYzfaEhp8kXuRYFTGBZQbtl41Vh9UYunzOWvAysnjSRF3ll7SneQ2EGbz+qt9TRVQ4opn8iHOFl3Zze/IU97199WaBcFXuUpxo/rZuBG91nCt3MIuq38JzqFkysTu0ElAK3AkQUY7dG7ncPqbFxdXaxlqXX7Hd9PkQiWnZTqGcRyBT+CgZZPd8/NIZTigf0RRCcY8g/IuXE4HxvvpMotbMsRfOzHOZTmSthWyh3/yTy4jQ==; 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 1Wcg3j-0000wG-Vy; Tue, 22 Apr 2014 12:08:48 -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:171589 Archived-At: This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --w2EPWWkWXxeqAwsERRjGjNW1Lwoi7Tkgb Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 04/22/2014 11:37 AM, Stefan Monnier wrote: >> Nobody is going to write a defmacro at toplevel inside a cl-letf. > I'm OK with adding a bit of complexity if it removes special cases > (which my proposal might do, tho I have no experience with it, so maybe= > it'll need horrendous hacks to implement and additionally it will > introduce new special cases),=20 I think it will need horrendous hacks (but maybe I'm wrong). We'd have to expand macros step-by-step and check recursively for macro-defining macros, and probably introduce some kind of special alternative defmacro in the environment, since the normal `defmacro' is itself a macro and would be hidden by macroexpand. (Imagine a macro that just expands to a single defmacro --- we'd still want to add that macro to our temporary environment.) To address this problem, we could merge macroexpand-1 instead, but that's an even bigger change. You also have to worry about nested macroexpand-all calls, leakage between defuns, and so on. There are interesting corner cases too: what about (progn (and nil (defmacro foo () ...)) (foo))? The current code works, solves a real problem, matches many other lisp implementations, and has automated tests. It doesn't affect (and slow) every macro expansion everywhere. > but the CL semantics adds complexity > without really removing special cases: it just moves the "special case > boundary" elsewhere. And I don't like it for that reason. > It's a question of taste, to a large extent, hence the bikeshedding. Your proposal is equivalent to sucking all the forms "following" (in some sense) a defmacro into an implicit macrolet that defines the same macro that the defmacro does. Fine. But how do you decide how much code is included in this implicit macrolet? All the remaining forms in the current call to macroexpand-all? That's too broad: a macro defined in one defun shouldn't affect forms in a completely different defun. The forms following the defmacro in the same progn? That's too narrow --- there's still a "special case boundary". I think that no matter where we choose to put the implicit macrolet, it'll surprise someone. I'd rather not try. Instead, we should address the case that's come up in practice (and that came up 20 years ago in Common Lisp). > I prefer you adding `eval-and-compile' at a few places to work around > the "buggy Elisp semantics" over imposing the CL semantics. I'm not going to do that. --w2EPWWkWXxeqAwsERRjGjNW1Lwoi7Tkgb 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/ iQIcBAEBAgAGBQJTVr4+AAoJEMAaIROpHW7ITQgQAIPJRobsgrZVoDU6h1XqNxo0 45p3ijI2okEmIV1WZpF88WN1HYaa451MU7gfuOHB6nyxjG7jdD+sJfJTTGjr2cLx tPxm8udf8q5rjIg0IlaC0/LGJ1fSgvhFPlxBtdZ8Y6kxACyjZncbEdweW0FaL2rL TX42qMlrpYrN1Y2HPA/4YaW2gcVJjHAT9O1EiboFKZUPvqTsrI6WWc3DPcYmMfbk AVUeJ/XbhURP5hD+ZoglnXl7sB/TU8uN3wNQ26lhemxa0RdQG38P06sEd68t/NtD /2nqQlcIMLoGBVAWQhgOdosuc9XH3it/m9SHwVl5pbRWwYMlipoT2sNQ6IVrPkdA wQLpEqy6vhPhMlKx+9qPD8+7zJ26eTtEhE//35vaGJjU6a3eudpk0ZaPR07rV6MN L639vz9XP2f74A4bJ20IcQmWxWq4srTd9nrGNc+HDPxOx4DA67oOrM2AiU6k6P5R Aa8BkqskWZJvJLKzqEUEzFK5UnQ7FlFfdwDGJi8eiHovKMDrXhwUuJblZlr659rr +KM+xBKUNP4ets0C7IoJWVpLECcM4LB/LIDnny/Om4CAu1JX8gGqkZ/oCqEbkBqD XwmdQzySxOYC1QKhXLfQ9nRG4CRmMs8iAZJqT80AfSaS2pdXWUhMi13pTwAF/jXx A6JWfLbjpYuC7YTGFzHQ =PjFF -----END PGP SIGNATURE----- --w2EPWWkWXxeqAwsERRjGjNW1Lwoi7Tkgb--