unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* 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  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  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  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).