all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* optimizing defconst
@ 2007-10-27 17:47 Dan Nicolaescu
  2007-10-27 20:32 ` Stefan Monnier
                   ` (2 more replies)
  0 siblings, 3 replies; 11+ messages in thread
From: Dan Nicolaescu @ 2007-10-27 17:47 UTC (permalink / raw)
  To: emacs-devel


Given this:

(defconst viper-xemacs-p (featurep 'xemacs))

(defun foo()
  (if viper-xemacs-p (error "Hmmmm")))


Shouldn't `foo' be optimized to just do nothing? 

It is not:

byte code for foo:
  args: nil
0 varref          viper-xemacs-p
1 goto-if-nil-else-pop 1
4 constant  error
5 constant  "Hmmmm"
6 call        1
7:1           return      

Am I missing something?

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: optimizing defconst
  2007-10-27 17:47 optimizing defconst Dan Nicolaescu
@ 2007-10-27 20:32 ` Stefan Monnier
  2007-10-28  2:28   ` Dan Nicolaescu
  2007-10-27 20:44 ` John Paul Wallington
  2007-10-27 21:17 ` Kim F. Storm
  2 siblings, 1 reply; 11+ messages in thread
From: Stefan Monnier @ 2007-10-27 20:32 UTC (permalink / raw)
  To: Dan Nicolaescu; +Cc: emacs-devel

> (defconst viper-xemacs-p (featurep 'xemacs))

> (defun foo()
>   (if viper-xemacs-p (error "Hmmmm")))

> Shouldn't `foo' be optimized to just do nothing? 

Can't do it: some code might do (setq viper-xemacs-p t) before calling
`foo'.  Such code might be flagged by the byte-compiler with a warning "setq
on a constant", but it's only a warning and it's not always caught.

We could change `defconst' so that it really defines constants (on which
`setq' fails) and then such an optimization might be acceptable, but this is
a non-trivial change.


        Stefan

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: optimizing defconst
  2007-10-27 17:47 optimizing defconst Dan Nicolaescu
  2007-10-27 20:32 ` Stefan Monnier
@ 2007-10-27 20:44 ` John Paul Wallington
  2007-10-27 21:17 ` Kim F. Storm
  2 siblings, 0 replies; 11+ messages in thread
From: John Paul Wallington @ 2007-10-27 20:44 UTC (permalink / raw)
  To: Dan Nicolaescu; +Cc: emacs-devel

Dan Nicolaescu <dann@ics.uci.edu> writes:

> Given this:
>
> (defconst viper-xemacs-p (featurep 'xemacs))
>
> (defun foo()
>   (if viper-xemacs-p (error "Hmmmm")))
>
>
> Shouldn't `foo' be optimized to just do nothing? 
>
> It is not:
[...]
> Am I missing something?

I suppose the question is whether there is lots of extant third-party
Emacs Lisp code that tries to set or let-bind constant variables and
if so whether it is worth breaking that code.  FWIW, I found that the
version of BBDB that I am using let-binds the constant variable
`bbdb-gag-messages'.

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: optimizing defconst
  2007-10-27 17:47 optimizing defconst Dan Nicolaescu
  2007-10-27 20:32 ` Stefan Monnier
  2007-10-27 20:44 ` John Paul Wallington
@ 2007-10-27 21:17 ` Kim F. Storm
  2 siblings, 0 replies; 11+ messages in thread
From: Kim F. Storm @ 2007-10-27 21:17 UTC (permalink / raw)
  To: Dan Nicolaescu; +Cc: emacs-devel

Dan Nicolaescu <dann@ics.uci.edu> writes:

> Given this:
>
> (defconst viper-xemacs-p (featurep 'xemacs))

Does using defsubst give better results?

>
> (defun foo()
>   (if viper-xemacs-p (error "Hmmmm")))
>
>
> Shouldn't `foo' be optimized to just do nothing? 
>
> It is not:
>
> byte code for foo:
>   args: nil
> 0 varref          viper-xemacs-p
> 1 goto-if-nil-else-pop 1
> 4 constant  error
> 5 constant  "Hmmmm"
> 6 call        1
> 7:1           return      
>
> Am I missing something?

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: optimizing defconst
  2007-10-27 20:32 ` Stefan Monnier
@ 2007-10-28  2:28   ` Dan Nicolaescu
  2007-10-29  0:11     ` Richard Stallman
  0 siblings, 1 reply; 11+ messages in thread
From: Dan Nicolaescu @ 2007-10-28  2:28 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: emacs-devel

Stefan Monnier <monnier@iro.umontreal.ca> writes:

  > > (defconst viper-xemacs-p (featurep 'xemacs))
  > 
  > > (defun foo()
  > >   (if viper-xemacs-p (error "Hmmmm")))
  > 
  > > Shouldn't `foo' be optimized to just do nothing? 
  > 
  > Can't do it: some code might do (setq viper-xemacs-p t) before calling
  > `foo'.  

One can make the argument that we can also use the analogy with
defmacro. If a macro is redefined at run time, the compiled code does
not know about it. It's not far fetched to do the same about defconst.

I am not necessarily saying that we should make that change, but at
least it would be nice to have this documented in the docstring for
defconst.

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: optimizing defconst
  2007-10-28  2:28   ` Dan Nicolaescu
@ 2007-10-29  0:11     ` Richard Stallman
  2007-10-29 10:46       ` Kim F. Storm
  0 siblings, 1 reply; 11+ messages in thread
From: Richard Stallman @ 2007-10-29  0:11 UTC (permalink / raw)
  To: Dan Nicolaescu; +Cc: monnier, emacs-devel

    One can make the argument that we can also use the analogy with
    defmacro. If a macro is redefined at run time, the compiled code does
    not know about it. It's not far fetched to do the same about defconst.

I don't want the compiler to optimize away defconst values.
It is asking for trouble (and it is work we don't need to do).

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: optimizing defconst
  2007-10-29  0:11     ` Richard Stallman
@ 2007-10-29 10:46       ` Kim F. Storm
  2007-10-29 11:08         ` Juanma Barranquero
                           ` (2 more replies)
  0 siblings, 3 replies; 11+ messages in thread
From: Kim F. Storm @ 2007-10-29 10:46 UTC (permalink / raw)
  To: rms; +Cc: Dan Nicolaescu, monnier, emacs-devel

Richard Stallman <rms@gnu.org> writes:

>     One can make the argument that we can also use the analogy with
>     defmacro. If a macro is redefined at run time, the compiled code does
>     not know about it. It's not far fetched to do the same about defconst.
>
> I don't want the compiler to optimize away defconst values.
> It is asking for trouble (and it is work we don't need to do).

What about an option to make a constant read-only, something like

(defconst ...
   :read-only t)

The C-code already checks that constants (e.g nil and t) are not
modified via SYMBOL_CONSTANT_P, so there is no extra work at the
C-level for such a change (except provide accessor functions
set-variable-read-only and variable-read-only for the "constant"
field of a variable).

Then the byte-compiler could check to see if a constant (or any
variable for that matter) is really read-only and optimize it away.

But I see that enable-multibyte-characters is marked as read-only -
not because it cannot change, but because we don't want users to
modify it directly.  

So to make the byte-compiler aware of such things, it may be necessary
to mark some constants as "are constant, but don't optimize away", e.g.:

(put 'enable-multibyte-characters 'bytecomp-dont-optimize)

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: optimizing defconst
  2007-10-29 10:46       ` Kim F. Storm
@ 2007-10-29 11:08         ` Juanma Barranquero
  2007-10-29 14:19         ` Johan Bockgård
  2007-10-30  2:14         ` Richard Stallman
  2 siblings, 0 replies; 11+ messages in thread
From: Juanma Barranquero @ 2007-10-29 11:08 UTC (permalink / raw)
  To: Kim F. Storm; +Cc: Dan Nicolaescu, emacs-devel, rms, monnier

On 10/29/07, Kim F. Storm <storm@cua.dk> wrote:

> What about an option to make a constant read-only, something like
>
> (defconst ...
>    :read-only t)

Two years ago there was some discussion, but Richard said he doesn't
want to add real constants because they are of no benefit:

 "I don't want to introduce defining of `real constants' in Emacs. It
would be added complexity that we don't need, and that as far as I can
see does not serve a purpose."

 "The question here is, `How will they help make Emacs better to edit with?'"

That said, Stefan had some quite interesting comments about constants
and non-mutable strings.

             Juanma

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: optimizing defconst
  2007-10-29 10:46       ` Kim F. Storm
  2007-10-29 11:08         ` Juanma Barranquero
@ 2007-10-29 14:19         ` Johan Bockgård
  2007-10-29 16:25           ` Davis Herring
  2007-10-30  2:14         ` Richard Stallman
  2 siblings, 1 reply; 11+ messages in thread
From: Johan Bockgård @ 2007-10-29 14:19 UTC (permalink / raw)
  To: emacs-devel

storm@cua.dk (Kim F. Storm) writes:

> What about an option to make a constant read-only, something like

    (if (featurep 'xemacs)
        (defvaralias 'viper-xemacs-p t)
      (defvaralias 'viper-xemacs-p nil))

    (setq viper-xemacs-p t)
       => Attempt to set a constant symbol: viper-xemacs-p

:)

-- 
Johan Bockgård

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: optimizing defconst
  2007-10-29 14:19         ` Johan Bockgård
@ 2007-10-29 16:25           ` Davis Herring
  0 siblings, 0 replies; 11+ messages in thread
From: Davis Herring @ 2007-10-29 16:25 UTC (permalink / raw)
  To: emacs-devel

>     (if (featurep 'xemacs)
>         (defvaralias 'viper-xemacs-p t)
>       (defvaralias 'viper-xemacs-p nil))
>
>     (setq viper-xemacs-p t)
>        => Attempt to set a constant symbol: viper-xemacs-p

...which of course simplifies to

(defvaralias 'viper-xemacs-p (featurep 'xemacs))

which is of course identical to `set' in interface, though it only
supports booleans (use "(not (not val))" to convert).  That's ...
intensely and simultaneously amusing and disgusting.

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: optimizing defconst
  2007-10-29 10:46       ` Kim F. Storm
  2007-10-29 11:08         ` Juanma Barranquero
  2007-10-29 14:19         ` Johan Bockgård
@ 2007-10-30  2:14         ` Richard Stallman
  2 siblings, 0 replies; 11+ messages in thread
From: Richard Stallman @ 2007-10-30  2:14 UTC (permalink / raw)
  To: Kim F. Storm; +Cc: dann, monnier, emacs-devel

    What about an option to make a constant read-only, something like

    (defconst ...
       :read-only t)

It is work which is not necessary.
It is better if we save our time for other things.

    Then the byte-compiler could check to see if a constant (or any
    variable for that matter) is really read-only and optimize it away.

It is a clean way to do this job, but this job does not need to be
done at all.

^ permalink raw reply	[flat|nested] 11+ messages in thread

end of thread, other threads:[~2007-10-30  2:14 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2007-10-27 17:47 optimizing defconst Dan Nicolaescu
2007-10-27 20:32 ` Stefan Monnier
2007-10-28  2:28   ` Dan Nicolaescu
2007-10-29  0:11     ` Richard Stallman
2007-10-29 10:46       ` Kim F. Storm
2007-10-29 11:08         ` Juanma Barranquero
2007-10-29 14:19         ` Johan Bockgård
2007-10-29 16:25           ` Davis Herring
2007-10-30  2:14         ` Richard Stallman
2007-10-27 20:44 ` John Paul Wallington
2007-10-27 21:17 ` Kim F. Storm

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.