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#7070: `load-time-value' local-vars this-kind and that-one Date: Sun, 07 Aug 2016 16:42:29 -0400 Message-ID: <87zioomhu2.fsf@users.sourceforge.net> References: NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1470602605 28758 195.159.176.226 (7 Aug 2016 20:43:25 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 7 Aug 2016 20:43:25 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) Cc: 7070@debbugs.gnu.org To: MON KEY Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Aug 07 22:43:20 2016 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 1bWUug-00061d-UK for geb-bug-gnu-emacs@m.gmane.org; Sun, 07 Aug 2016 22:43:15 +0200 Original-Received: from localhost ([::1]:53806 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bWUud-0000YB-RW for geb-bug-gnu-emacs@m.gmane.org; Sun, 07 Aug 2016 16:43:11 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35825) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bWUuX-0000Wr-MV for bug-gnu-emacs@gnu.org; Sun, 07 Aug 2016 16:43:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bWUuU-0003mf-G2 for bug-gnu-emacs@gnu.org; Sun, 07 Aug 2016 16:43:05 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:33713) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bWUuU-0003mZ-CH for bug-gnu-emacs@gnu.org; Sun, 07 Aug 2016 16:43:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1bWUuU-00082F-1m for bug-gnu-emacs@gnu.org; Sun, 07 Aug 2016 16:43: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: Sun, 07 Aug 2016 20:43:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 7070 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 7070-submit@debbugs.gnu.org id=B7070.147060256230862 (code B ref 7070); Sun, 07 Aug 2016 20:43:02 +0000 Original-Received: (at 7070) by debbugs.gnu.org; 7 Aug 2016 20:42:42 +0000 Original-Received: from localhost ([127.0.0.1]:59243 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bWUuA-00081d-Fu for submit@debbugs.gnu.org; Sun, 07 Aug 2016 16:42:42 -0400 Original-Received: from mail-io0-f172.google.com ([209.85.223.172]:36447) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bWUu8-00081I-7k; Sun, 07 Aug 2016 16:42:41 -0400 Original-Received: by mail-io0-f172.google.com with SMTP id b62so342135077iod.3; Sun, 07 Aug 2016 13:42:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=RikuYmPwTClOpvPXpn/aPKI0/SHfd8cO6FdHYkHEyLs=; b=ofoS6TK7920aYPt/Fieqxt9l4X3zPvCAN9kWdjWWkhYih4WHRZfe0tF87P/X5YHMe3 jPDGWcSxQnJssyfXk76p/Z8EdYXf8d7lym887ViLRZVlitlgk3L8sSfGEjQFilOcKQXv rf793+u2/6Zctia1DkQxB7+wMxaQqF7M4YUIjl3Bm/OiZZ+Mrvq6/G8IKVryCQHG7t1r 1+07Rvegxba5YhF2MrWjZrUT84/dV6ajjOFPK9L0iX0SFi0qDhTdbPzWjNpDjUPkddvn d4uL+pp6S53CEx/E/oC1CJ7x4yjWLf/FGUblYi216f12K9pSUIuoB6dye9ovT3Ri1JF2 MqKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:from:to:cc:subject:references:date :in-reply-to:message-id:user-agent:mime-version; bh=RikuYmPwTClOpvPXpn/aPKI0/SHfd8cO6FdHYkHEyLs=; b=l0pQt78iYig5hk0DunL7L2t18K1d6mTQJdk+KkHKO0YKK+lyzEXIhuP3FxmCRt7j13 K+N5jL3qPPetfkjlwtXI4ZHy6wqxp/NS2ODYsaBzUABgNxlmuwf0ljb/H9s5fQeJPquM 0rDfvq6hK6TnxaI4PSQvp0hGXuBfNRvRQHY2izOnNDbSvPM06iNrpZhetnEop2eKUOuY Q6QNdh9k3vI62WA5pSGNqnQmbb9gO5mU/VgZRi1rnp/eSfMYQzm/YkTlL+t0yjzCh4aI qxlV8wiygwFAbezJsOOBgWj7Ro9pgqlSOY+u3VYs4tpsPx3Fx3IOyx+ja1CkB/fSMHmM zalQ== X-Gm-Message-State: AEkoouun8FuHBWs7cKFAZ2t6XgQRZjVhEa5XemmsjE9YD1O22TMTsbQ/dbu5rdMMD278Ew== X-Received: by 10.107.173.234 with SMTP id m103mr98458356ioo.127.1470602554378; Sun, 07 Aug 2016 13:42:34 -0700 (PDT) Original-Received: from zony (206-188-64-44.cpe.distributel.net. [206.188.64.44]) by smtp.googlemail.com with ESMTPSA id e10sm7047514iof.41.2016.08.07.13.42.32 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 07 Aug 2016 13:42:33 -0700 (PDT) In-Reply-To: (MON KEY's message of "Sat, 18 Sep 2010 21:43:55 -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:121947 Archived-At: severity 7070 minor quit MON KEY writes: > current through BZR-101480 lisp/cl-macs.el macro `load-time-value' has this > branch which if unsatisfied is supposed to fset `byte-compile-file-form': > > (and (fboundp 'byte-compile-file-form-defmumble) > (boundp 'this-kind) (boundp 'that-one)) > > However, luckily the above doesn't happen. > > The only locations that bind the variables like this are in > byte-compile-file-form-defmumble' e.g. the local letbound vars > bytecomp-this-kind' and `bytecomp-that-one'. [...] > > Revision 96701 renamed the `byte-compile-file-form-defmumble's local vars: > > `this-kind' -> `bytecomp-this-kind' > `this-one' -> `bytecomp-this-one' > `that-one' -> `bytecomp-that-one' > `outbuffer' -> `bytecomp-outbuffer' > > Revision 96702 renamed the `load-time-value' local var: > > `outbuffer' -> `bytecomp-outbuffer' > > but it appears to have left the `this-one' and `this-kind' vars unchanged. Meanwhile, bytecomp.el has switched to lexical binding, so the names of this-kind and that-one are irrelevant; they will never be bound. > > Unless I am misunderstanding/missing something either: > > a) some special magic that happens invisibily when Emacs is dumped and the > current constraint is some sort of backward compatibility kludge; > > b) the macro never worked correctly; > > c) revisions at 96701/96702 created a bug where `load-time-value's can no longer > alter via fset the function cell of `byte-compile-file-form' because the > following constraint can not be satisfied; > > d) the macro never worked correctly and revisions at 96701/96702 created an > additional bug; > > My money is on d. I'm not sure about past behaviour, but with current Emacs, the macro does appear to work correctly. AFAICT, it's because the condition the boundp calls are trying to protect against (that the compiler is in the middle of printing out a function's code) never occurs because the compiler prints the code of a function in a single shot (perhaps because it has to run optimizations on the whole function before printing?). In other words this macro could be simplified to (defmacro cl-load-time-value (form &optional _read-only) "Like `progn', but evaluates the body at load time. The result of the body appears to the compiler as a quoted constant." (declare (debug (form &optional sexp))) (if (cl--compiling-file) (let* ((temp (cl-gentemp "--cl-load-time--"))) ;; Assume there are no unclosed parens in ;; `byte-compile--outbuffer'. (print `(setq ,temp ,form) byte-compile--outbuffer) temp) `',(eval form))) And it should probably use `defconst' instead of `setq' to avoid a free variable warning. > > Also, what does the READ-ONLY arg do? > > The only possibility I can think of is that it somehow dovetails with the > :read-only key in defstruct. It does nothing in Emacs' implementation, perhaps it could use `purecopy'? Although that would still do nothing most of the time, so maybe it's not worth the trouble. According to cltl (https://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node224.html) The optional read-only-p argument designates whether the result may be considered a read-only constant. If nil (the default), the result must be considered ordinary, modifiable data. If t, the result is a read-only quantity that may, as appropriate, be copied into read-only space and may, as appropriate, be shared with other programs. The read-only-p argument is not evaluated and only the literal symbols t and nil are permitted.