From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: npostavs@users.sourceforge.net Newsgroups: gmane.emacs.bugs Subject: bug#27016: possible bug in `defsetf' Date: Mon, 22 May 2017 19:15:57 -0400 Message-ID: <87a864fpoy.fsf@users.sourceforge.net> References: NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1495494913 30926 195.159.176.226 (22 May 2017 23:15:13 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 22 May 2017 23:15:13 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux) Cc: 27016@debbugs.gnu.org To: Rafael D Sorkin Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue May 23 01:15:08 2017 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dCwXb-0007vD-QQ for geb-bug-gnu-emacs@m.gmane.org; Tue, 23 May 2017 01:15:08 +0200 Original-Received: from localhost ([::1]:45283 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dCwXh-0002Oz-9L for geb-bug-gnu-emacs@m.gmane.org; Mon, 22 May 2017 19:15:13 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37529) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dCwXa-0002NE-70 for bug-gnu-emacs@gnu.org; Mon, 22 May 2017 19:15:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dCwXX-0002LA-16 for bug-gnu-emacs@gnu.org; Mon, 22 May 2017 19:15:06 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:59011) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dCwXW-0002L5-Rp for bug-gnu-emacs@gnu.org; Mon, 22 May 2017 19:15:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1dCwXW-0004yD-Fv for bug-gnu-emacs@gnu.org; Mon, 22 May 2017 19:15:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: npostavs@users.sourceforge.net Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 22 May 2017 23:15:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 27016 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 27016-submit@debbugs.gnu.org id=B27016.149549486719051 (code B ref 27016); Mon, 22 May 2017 23:15:02 +0000 Original-Received: (at 27016) by debbugs.gnu.org; 22 May 2017 23:14:27 +0000 Original-Received: from localhost ([127.0.0.1]:33455 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dCwWw-0004xD-Ng for submit@debbugs.gnu.org; Mon, 22 May 2017 19:14:26 -0400 Original-Received: from mail-it0-f54.google.com ([209.85.214.54]:37798) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dCwWv-0004x0-8N for 27016@debbugs.gnu.org; Mon, 22 May 2017 19:14:25 -0400 Original-Received: by mail-it0-f54.google.com with SMTP id g126so8514618ith.0 for <27016@debbugs.gnu.org>; Mon, 22 May 2017 16:14:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=JdjwtOZGo8cIFHTpB0zB3atQ+kxbfS6bj0mpfVWD4so=; b=aqBHg2VcKaiU3+6ybPxlldw5nCwJmKBetDnQxfGR4aQ9+SfFELx9AS1Dypghd3uqC+ fmrWYgCkVfuBjgMjbdEJa6q7jLfczjjQyPe+3covO9H+pjEDdKzqpDi8pjIT09PeiFyv GFdHOYjsE3Lx831zWCX4/MNhiBDDEKRn9iIgmyGXFbDECsxbp+jiKhRA0XruNtJv66HY f2xNtwL5vhwfkJw7OxMei5aMCOJInNM6Hhx+qOjmiDlAWNkt+H1HDRr8vaFKmaU9+YhM L7i3lV+BY7IhyRxAolUGoX80A6M4yo1xXIlIlOeqdcOz9XUWHDJYGDoKiJMyAUoOxOPE /BcQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:to:cc:subject:references:date :in-reply-to:message-id:user-agent:mime-version; bh=JdjwtOZGo8cIFHTpB0zB3atQ+kxbfS6bj0mpfVWD4so=; b=oFit/xZwUwrGvwDlUhdjrz9fIdfVeLfC1zq2kzxrfUuYqXSecZK8brzpPuhG045LM/ +i7Tz512cs1zH8vJQvcDoD6C1wNV5GpTXE5G+es+5BLNWUmYhSjN8cU8uzn+43FKYTnK t7C2fLFFSaCpJIcfhXdpejI6DplJT8nxerhCM1F+ds59UMfKIGCudAp87WzLuvsQltfj eCx6x2pPR2m5OJG5QhxlXXTRFaXYSVuV+If8Dhs4JCGlruihHlMjn6mMdwkFPXCEw2C5 kXsJRDPam1bmGoSFesyPlONBiSgGJRqnCVi677HlTtYO382xF1LeTOigU6LQgWpY0hqk /ZpA== X-Gm-Message-State: AODbwcBvL9L8HLPWutUK+tdn35ab+flT/a5YZ6VObklpR2nXqqvHTlCd fY1JvzWLruc4mw== X-Received: by 10.107.23.66 with SMTP id 63mr23708143iox.184.1495494859481; Mon, 22 May 2017 16:14:19 -0700 (PDT) Original-Received: from zony ([45.2.7.65]) by smtp.googlemail.com with ESMTPSA id b10sm8287014iod.33.2017.05.22.16.14.18 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 22 May 2017 16:14:18 -0700 (PDT) In-Reply-To: (Rafael D. Sorkin's message of "Mon, 22 May 2017 18:03:08 -0400") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:132751 Archived-At: Rafael D Sorkin writes: > Thanks, I was wondering about that myself. Is there a standard > for elisp (or common lisp) that would determine whether eager > macro expansion is an error in this case? CLTL says this[1]: The evaluator is typically implemented as an interpreter that traverses the given form recursively, performing each step of the computation as it goes. An interpretive implementation is not required, however. A permissible alternative approach is for the evaluator first to completely compile the form into machine-executable code and then invoke the resulting code. This technique virtually eliminates incompatibilities between interpreted and compiled code but also renders the evalhook mechanism relatively useless. Various mixed strategies are also possible. All of these approaches should produce the same results when executing a correct program but may produce different results for incorrect programs. For example, the approaches may differ as to when macro calls are expanded; macro definitions should not depend on the time at which they are expanded. Implementors should document the evaluation strategy for each implementation. and this[2] specifically about defsetf: X3J13 voted in March 1989 (DEFINING-MACROS-NON-TOP-LEVEL) to clarify that, while defining forms normally appear at top level, it is meaningful to place them in non-top-level contexts; the complex form of defsetf must define the expander function within the enclosing lexical environment, not within the global environment. I'm not sure whether (unless ...) counts as an "enclosing lexical environment" though. > I would expect that a `defun' or `defsetf' etc which is within a > conditional would not be executed until it was known whether the > condition was satisfied. The opposite behavior seems > counter-intuitive to me. `defun' takes effect at runtime (or rather it expands to `defalias' which operates at runtime), whereas `defsetf' has to affect subsequent compilation, so waiting until runtime to decide whether the condition is true could not really work. > But if you decide that this behavior is not a bug, then please > let me know, so that I can adapt to it in the future. I *think* it's not a bug, or at least not one worth fixing. If you wrap your (unless ...) form in (eval-when-compile ...) then you get your expected behaviour. [1]: https://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node179.html [2]: https://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node80.html