* bug#13052: 24.3.50; mention recent change of `kbd' to a function in NEWS @ 2012-12-02 0:28 Drew Adams 2012-12-02 1:52 ` Juanma Barranquero 2012-12-02 9:14 ` Chong Yidong 0 siblings, 2 replies; 13+ messages in thread From: Drew Adams @ 2012-12-02 0:28 UTC (permalink / raw) To: 13052 1. Subject line says it all. 2. Also, I don't recall (and cannot seem to find) any discussion of this in emacs-devel@gnu.org. I have no objection to the change, but I'm curious: what was the reason? Is there something new, or was it just so you can funcall it etc.? 3. (put 'kbd 'pure t) What does putting non-nil property `pure' on a function symbol do? Does it mean that the definition will stored in pure storage? How about documenting this `pure' property? For example (assuming it is appropriate), in (elisp) `Pure Storage'. In GNU Emacs 24.3.50.1 (i386-mingw-nt5.1.2600) of 2012-11-19 on MS-W7-DANI Bzr revision: 110950 monnier@iro.umontreal.ca-20121119182725-5p6w4wjimm7epggr Windowing system distributor `Microsoft Corp.', version 5.1.2600 Configured using: `configure --with-gcc (4.7) --no-opt --enable-checking --cflags -Ic:/emacs/libs/libXpm-3.5.10/include -Ic:/emacs/libs/libXpm-3.5.10/src -Ic:/emacs/libs/libpng-1.2.37-lib/include -Ic:/emacs/libs/zlib-1.2.5 -Ic:/emacs/libs/giflib-4.1.4-1-lib/include -Ic:/emacs/libs/jpeg-6b-4-lib/include -Ic:/emacs/libs/tiff-3.8.2-1-lib/include -Ic:/emacs/libs/libxml2-2.7.8-w32-bin/include/libxml2 -Ic:/emacs/libs/gnutls-3.0.9-w32-bin/include -Ic:/emacs/libs/libiconv-1.9.2-1-lib/include' ^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#13052: 24.3.50; mention recent change of `kbd' to a function in NEWS 2012-12-02 0:28 bug#13052: 24.3.50; mention recent change of `kbd' to a function in NEWS Drew Adams @ 2012-12-02 1:52 ` Juanma Barranquero 2012-12-02 2:18 ` Drew Adams 2012-12-02 9:14 ` Chong Yidong 1 sibling, 1 reply; 13+ messages in thread From: Juanma Barranquero @ 2012-12-02 1:52 UTC (permalink / raw) To: Drew Adams; +Cc: 13052 On Sun, Dec 2, 2012 at 1:28 AM, Drew Adams <drew.adams@oracle.com> wrote: > 3. (put 'kbd 'pure t) > What does putting non-nil property `pure' on a function symbol do? Does > it mean that the definition will stored in pure storage? It's not related to pure storage, but to whether the function is "pure" (without side effecs). If the function is pure and the arguments satisfy `macroexp-const-p' it is possible to do some optimization during byte-compilation. See lisp/emacs-lisp/byte-opt.el, around line 560 or so. J ^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#13052: 24.3.50; mention recent change of `kbd' to a function in NEWS 2012-12-02 1:52 ` Juanma Barranquero @ 2012-12-02 2:18 ` Drew Adams 2012-12-02 2:26 ` Juanma Barranquero 2012-12-02 11:33 ` Michael Heerdegen 0 siblings, 2 replies; 13+ messages in thread From: Drew Adams @ 2012-12-02 2:18 UTC (permalink / raw) To: 'Juanma Barranquero'; +Cc: 13052 > It's not related to pure storage, but to whether the function is > "pure" (without side effecs). If the function is pure and the > arguments satisfy `macroexp-const-p' it is possible to do some > optimization during byte-compilation. See lisp/emacs-lisp/byte-opt.el, > around line 560 or so. Thanks. So I guess that means that if I have a similar (e.g., identical, for discussion) function and I put property `pure' on it then I will get the same optimization? I was thinking this had something to do with pure storage, so it would do no good to add that property to code I write. Is the only requirement that the function have no side effects and each of its arguments satisfies `macroexp-const-p'? What happens if someone erroneously adds that property to a function that is not pure but whose args all satisfy `macroexp-const-p'? Do you just lose the optimization or could something much worse happen? Looking at the byte-opt.el code briefly, it looks like the byte code would be incorrect. It looks as if adding non-nil property `pure' is a pretty strong declaration to the compiler, not just a hint, and it could have bad results if applied in the wrong place. Am I reading that right? In any case, this property should be documented. ^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#13052: 24.3.50; mention recent change of `kbd' to a function in NEWS 2012-12-02 2:18 ` Drew Adams @ 2012-12-02 2:26 ` Juanma Barranquero 2012-12-02 3:36 ` Drew Adams 2012-12-02 11:33 ` Michael Heerdegen 1 sibling, 1 reply; 13+ messages in thread From: Juanma Barranquero @ 2012-12-02 2:26 UTC (permalink / raw) To: Drew Adams; +Cc: 13052 On Sun, Dec 2, 2012 at 3:18 AM, Drew Adams <drew.adams@oracle.com> wrote: > Thanks. So I guess that means that if I have a similar (e.g., identical, for > discussion) function and I put property `pure' on it then I will get the same > optimization? I think so, though I haven't really looked that much at byte-opt's code. > What happens if someone erroneously adds that property to a function that is not > pure but whose args all satisfy `macroexp-const-p'? Do you just lose the > optimization or could something much worse happen? I suppose (but again, I haven't studied the code) that some calls to that function would likely be optimized away, which would cause erroneous execution in case the function really does have side effects. > In any case, this property should be documented. Not surprisingly, I disagree. I don't think it is intended to be used by third-party packages. Documenting it is asking for trouble. Juanma ^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#13052: 24.3.50; mention recent change of `kbd' to a function in NEWS 2012-12-02 2:26 ` Juanma Barranquero @ 2012-12-02 3:36 ` Drew Adams 2012-12-02 3:50 ` Juanma Barranquero 0 siblings, 1 reply; 13+ messages in thread From: Drew Adams @ 2012-12-02 3:36 UTC (permalink / raw) To: 'Juanma Barranquero'; +Cc: 13052 > > In any case, this property should be documented. > > I don't think it is intended to be used by third-party packages. Why? What makes it special? Do you know a reason, or are you just saying that? ^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#13052: 24.3.50; mention recent change of `kbd' to a function in NEWS 2012-12-02 3:36 ` Drew Adams @ 2012-12-02 3:50 ` Juanma Barranquero 2012-12-02 4:07 ` Drew Adams 0 siblings, 1 reply; 13+ messages in thread From: Juanma Barranquero @ 2012-12-02 3:50 UTC (permalink / raw) To: Drew Adams; +Cc: 13052 > Why? What makes it special? Do you really think that there are many things in byte-opt.el intended for third-party packages? The only reference to it in the docs is in Writing Emacs Primitives, which is not exactly lisp-level stuff. Juanma ^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#13052: 24.3.50; mention recent change of `kbd' to a function in NEWS 2012-12-02 3:50 ` Juanma Barranquero @ 2012-12-02 4:07 ` Drew Adams 2012-12-02 4:19 ` Juanma Barranquero 0 siblings, 1 reply; 13+ messages in thread From: Drew Adams @ 2012-12-02 4:07 UTC (permalink / raw) To: 'Juanma Barranquero'; +Cc: 13052 > > Why? What makes it special? > > Do you really think that there are many things in byte-opt.el intended > for third-party packages? The only reference to it in the docs is in > Writing Emacs Primitives, which is not exactly lisp-level stuff. The application of property `pure' to `kbd' is not in byte-opt.el. It is in subr.el. And in my code it would, likewise, be in an ordinary Lisp library. I was just asking whether you know of something that makes this special to Emacs Dev and not appropriate for user libraries. If you don't know of anything, fine; perhaps someone else does. It is a question: whether `pure' is information that users can reasonably use to inform the byte compiler that a function is what the compiler would expect of a pure function, i.e., what the code you pointed me to would expect, in order to be able to perform that particular optimization. ^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#13052: 24.3.50; mention recent change of `kbd' to a function in NEWS 2012-12-02 4:07 ` Drew Adams @ 2012-12-02 4:19 ` Juanma Barranquero 2012-12-02 4:50 ` Drew Adams 0 siblings, 1 reply; 13+ messages in thread From: Juanma Barranquero @ 2012-12-02 4:19 UTC (permalink / raw) To: Drew Adams; +Cc: 13052 On Sun, Dec 2, 2012 at 5:07 AM, Drew Adams <drew.adams@oracle.com> wrote: > The application of property `pure' to `kbd' is not in byte-opt.el. It is in > subr.el. And in my code it would, likewise, be in an ordinary Lisp library. I wouldn't call subr.el "an ordinary Lisp library"; perhaps it's the word "basic" in "basic lisp subroutines for Emacs". > I was just asking whether you know of something that makes this special to Emacs > Dev and not appropriate for user libraries. If you don't know of anything, > fine; perhaps someone else does. No, I don't know of something that makes it special to Emacs, other than the interiorities of the byte-optimizer are undocumented except in the source code. It's almost by definition what I would call "internal". I suppose we will have to agree to disagree on this, because I don't share your impulse to document every nook and cranny of Emacs. > It is a question: whether `pure' is information that users can reasonably use to > inform the byte compiler that a function is what the compiler would expect of a > pure function, i.e., what the code you pointed me to would expect, in order to > be able to perform that particular optimization. If it were so, it would be documented, don't you think. In the section of the Elisp manual dedicated to the byte-optimizer. Only that section does not exist. J ^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#13052: 24.3.50; mention recent change of `kbd' to a function in NEWS 2012-12-02 4:19 ` Juanma Barranquero @ 2012-12-02 4:50 ` Drew Adams 0 siblings, 0 replies; 13+ messages in thread From: Drew Adams @ 2012-12-02 4:50 UTC (permalink / raw) To: 'Juanma Barranquero'; +Cc: 13052 > > The application of property `pure' to `kbd' is not in > > byte-opt.el. It is in subr.el. And in my code it would, > > likewise, be in an ordinary Lisp library. > > I wouldn't call subr.el "an ordinary Lisp library"; perhaps it's the > word "basic" in "basic lisp subroutines for Emacs". You can argue that merely by virtue of belonging to the GNU Emacs distribution none of its libraries is completely "ordinary" - they are not user libraries. I meant that it is not special wrt byte-compiling or the byte compiler (AFAIK). If you want to say that wrt the use of `pure' it is more special than my library `foo', then it behooves you to say what makes it special wrt byte-compiling. That is my question. > > I was just asking whether you know of something that makes > > this special to Emacs Dev and not appropriate for user > > libraries. If you don't know of anything, fine; perhaps > > someone else does. > > No, I don't know of something that makes it special to Emacs, other > than the interiorities of the byte-optimizer are undocumented except > in the source code. It's almost by definition what I would call > "internal". I was not asking what makes byte-opt.el special wrt byte-compiling. I was asking what makes subr.el - in particular, its definition of `kbd', special. Why would it be appropriate to apply `pure' to `kbd' but not to a user function `foo' with the same definition? I'm trying to understand/learn. > I suppose we will have to agree to disagree on this, because I don't > share your impulse to document every nook and cranny of Emacs. Hyperbole. Let's please stick to this bug report and documentation of this feature of applying property `pure'. > > It is a question: whether `pure' is information that users > > can reasonably use to inform the byte compiler that a function > > is what the compiler would expect of a pure function, i.e., > > what the code you pointed me to would expect, in order to > > be able to perform that particular optimization. > > If it were so, it would be documented, don't you think. No, I don't think that is necessarily the case (`if it should be documented it would already be documented'). Any more than the fact that the change of `kbd' to a function is documented in NEWS. That is a recent change, and perhaps someone has just not yet had a chance to update NEWS. Is the use of `pure' recent also? Grepping Emacs 23.4 I find 4 occurrences outside byte-opt.el (all in smie.el), so it is at least that old. Grepping Emacs 22.3 I find only one occurrence, which is in byte-opt.el itself. Grepping Emacs 21.3.1 I find no occurrences. So it has been around for a while, but clearly it has not been used much so far, even by Emacs Dev. (The self-documentation of Emacs is for Emacs Dev too, BTW.) > In the section of the Elisp manual dedicated to the > byte-optimizer. Only that section does not exist. There is a section that is about compiler declarations, but so far it is specific to `declare-function'. That seems to be the only compiler declaration Emacs Lisp has, so far (?). Perhaps the use of `pure', if appropriate for users (still my question), could be elevated to a declaration form: `declare-pure' or whatever. (And there are of course other user forms that affect byte compilation in some way, such as `with-no-warnings'.) ^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#13052: 24.3.50; mention recent change of `kbd' to a function in NEWS 2012-12-02 2:18 ` Drew Adams 2012-12-02 2:26 ` Juanma Barranquero @ 2012-12-02 11:33 ` Michael Heerdegen 1 sibling, 0 replies; 13+ messages in thread From: Michael Heerdegen @ 2012-12-02 11:33 UTC (permalink / raw) To: Drew Adams; +Cc: Juanma Barranquero, 13052 "Drew Adams" <drew.adams@oracle.com> writes: > > It's not related to pure storage, but to whether the function is > > "pure" (without side effecs). If the function is pure and the > > arguments satisfy `macroexp-const-p' it is possible to do some > > optimization during byte-compilation. See lisp/emacs-lisp/byte-opt.el, > > around line 560 or so. > > Thanks. So I guess that means that if I have a similar (e.g., > identical, for discussion) function and I put property `pure' on it > then I will get the same optimization? Looking shortly at the code, I see this paragraph, which seems to say it all: ;; pure functions are side-effect free functions whose values depend ;; only on their arguments. For these functions, calls with constant ;; arguments can be evaluated at compile time. This may shift run time ;; errors to compile time. So, IIUC, the only optimization you get is that errors happen at compile-time that would otherwise happen at run-time. E.g. like for (symbol-name "Not-a-symbol") OTOH, this would become a string when compiled (because it's evaluated at compile-time): (symbol-name 'a-symbol) > What happens if someone erroneously adds that property to a function > that is not pure but whose args all satisfy `macroexp-const-p'? Do > you just lose the optimization or could something much worse happen? The funcall and the side-effects happen at compile-time. In most cases, this is probably quite bad. > In any case, this property should be documented. If I understood the code correctly, this could indeed be a bit useful. But maybe it is still experimental... it's no big loss not to use it. And we can be happy that it is no "Do not use this". Regards, Michael. ^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#13052: 24.3.50; mention recent change of `kbd' to a function in NEWS 2012-12-02 0:28 bug#13052: 24.3.50; mention recent change of `kbd' to a function in NEWS Drew Adams 2012-12-02 1:52 ` Juanma Barranquero @ 2012-12-02 9:14 ` Chong Yidong 2012-12-02 17:13 ` Drew Adams 2012-12-06 18:02 ` Drew Adams 1 sibling, 2 replies; 13+ messages in thread From: Chong Yidong @ 2012-12-02 9:14 UTC (permalink / raw) To: Drew Adams; +Cc: 13052-done "Drew Adams" <drew.adams@oracle.com> writes: > 1. Subject line says it all. Fixed, thanks. As for the `pure' property, it's now mentioned in the Lisp manual. ^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#13052: 24.3.50; mention recent change of `kbd' to a function in NEWS 2012-12-02 9:14 ` Chong Yidong @ 2012-12-02 17:13 ` Drew Adams 2012-12-06 18:02 ` Drew Adams 1 sibling, 0 replies; 13+ messages in thread From: Drew Adams @ 2012-12-02 17:13 UTC (permalink / raw) To: 'Chong Yidong'; +Cc: 13052-done > > 1. Subject line says it all. > > Fixed, thanks. > > As for the `pure' property, it's now mentioned in the Lisp manual. Thank you. I would still like to know this (about the change of `kbd' to a function): d> 2. Also, I don't recall (and cannot seem to find) any d> discussion of this in emacs-devel@gnu.org. I have no d> objection to the change, but I'm curious: what was the d> reason? Is there something new, or was it just so d> you can funcall it etc.? ^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#13052: 24.3.50; mention recent change of `kbd' to a function in NEWS 2012-12-02 9:14 ` Chong Yidong 2012-12-02 17:13 ` Drew Adams @ 2012-12-06 18:02 ` Drew Adams 1 sibling, 0 replies; 13+ messages in thread From: Drew Adams @ 2012-12-06 18:02 UTC (permalink / raw) To: 'Chong Yidong'; +Cc: 13052-done, 13052 > As for the `pure' property, it's now mentioned in the Lisp manual. It is now mentioned, but this is all the manual says about it: This property is used internally to mark certain named functions for byte compiler optimization. Do not set it. Please explain why it is not appropriate for users to use this property on their own functions. That is not clear at all. Why shouldn't a user function with a definition similar or even identical to that for `kbd' have `pure' applied to it? Especially since this apparently affects only byte-compilation and has nothing to do with pure storage and dumping Emacs. What is your reason for declaring this off-limits for programmers of Emacs Lisp? What good does that do? ^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2012-12-06 18:02 UTC | newest] Thread overview: 13+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2012-12-02 0:28 bug#13052: 24.3.50; mention recent change of `kbd' to a function in NEWS Drew Adams 2012-12-02 1:52 ` Juanma Barranquero 2012-12-02 2:18 ` Drew Adams 2012-12-02 2:26 ` Juanma Barranquero 2012-12-02 3:36 ` Drew Adams 2012-12-02 3:50 ` Juanma Barranquero 2012-12-02 4:07 ` Drew Adams 2012-12-02 4:19 ` Juanma Barranquero 2012-12-02 4:50 ` Drew Adams 2012-12-02 11:33 ` Michael Heerdegen 2012-12-02 9:14 ` Chong Yidong 2012-12-02 17:13 ` Drew Adams 2012-12-06 18:02 ` Drew Adams
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).