optimizing defconst

optimizing defconst

[Dan Nicolaescu]

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?

Re: optimizing defconst

[Stefan Monnier]

> (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

Re: optimizing defconst

[John Paul Wallington]

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'.

Re: optimizing defconst

[Kim F. Storm]

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

Re: optimizing defconst

[Dan Nicolaescu]

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.

Re: optimizing defconst

[Richard Stallman]

    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).

Re: optimizing defconst

[Kim F. Storm]

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

Re: optimizing defconst

[Juanma Barranquero]

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

Re: optimizing defconst

[Johan Bockgård]

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

Re: optimizing defconst

[Davis Herring]

>     (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.

Re: optimizing defconst

[Richard Stallman]

    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.