defvar'ing constants

defvar'ing constants

[Juanma Barranquero]

*** Welcome to IELM ***  Type (describe-mode) for help.
ELISP> (defvar :k)
:k
ELISP> (defvar :k 1)
:k
ELISP> (defconst :k 1)
*** Eval error ***  Attempt to set a constant symbol: :k
ELISP> (set :k :k)
:k
ELISP> (set :k 1)
*** Eval error ***  Attempt to set a constant symbol: :k
ELISP> (set-default :k :k)
:k
ELISP> (set-default :k 1)
*** Eval error ***  Attempt to set a constant symbol: :k
ELISP> 

For consistency:

  (defvar CONSTANT)               ; should work
  (defvar CONSTANT ITS-VALUE)     ; should work
  (defvar CONSTANT OTHER-VALUE)   ; should fail

The attached patch implements this behavior.  I'm calling error
directly, copying the error message from set_internal; another idea
would be to allow the call to Fset_default to go through when

   NILP (tem) ||
   (SYMBOL_CONSTANT_P (sym) && !EQ (tem, tail))

which avoid duplicating the error checking and the message, but
doesn't seem clean to me.  Opinions?

-- 
                    /L/e/k/t/u


Index: src/eval.c
===================================================================
RCS file: /cvsroot/emacs/emacs/src/eval.c,v
retrieving revision 1.243
diff -u -2 -r1.243 eval.c
--- src/eval.c	23 Jun 2005 16:07:51 -0000	1.243
+++ src/eval.c	24 Jun 2005 03:42:47 -0000
@@ -793,4 +793,8 @@
       if (NILP (tem))
  	Fset_default (sym, Feval (Fcar (tail)));
+      else if (SYMBOL_CONSTANT_P (sym)
+               && !EQ (tem, tail))
+        error ("Attempt to set a constant symbol: %s",
+               SDATA (SYMBOL_NAME (sym)));
       else
 	{ /* Check if there is really a global binding rather than just a let

Re: defvar'ing constants

[Richard M. Stallman]

    For consistency:

      (defvar CONSTANT)               ; should work
      (defvar CONSTANT ITS-VALUE)     ; should work
      (defvar CONSTANT OTHER-VALUE)   ; should fail

I think it is more consistent to make them all errors.
defvar should not be used on these symbols.

Re: defvar'ing constants

[Jay Belanger]

"Richard M. Stallman" <rms@gnu.org> writes:

>     For consistency:
>
>       (defvar CONSTANT)               ; should work
>       (defvar CONSTANT ITS-VALUE)     ; should work
>       (defvar CONSTANT OTHER-VALUE)   ; should fail
>
> I think it is more consistent to make them all errors.
> defvar should not be used on these symbols.

If a constant is defined in one file but used in a second, is there
then a way of quieting the compiler when the second file is compiled?

Re: defvar'ing constants

[Juanma Barranquero]

> I think it is more consistent to make them all errors.
> defvar should not be used on these symbols.

OK, that's even easier. I'll implement it.

-- 
                    /L/e/k/t/u

Re: defvar'ing constants

[Juanma Barranquero]

> If a constant is defined in one file but used in a second, is there
> then a way of quieting the compiler when the second file is compiled?

"Constants", in the sense used in this thread, are not defconsts
(which are really mutable), but keywords, and symbols defined in C
which are marked as constant (for example,
`enable-multibyte-characters').

-- 
                    /L/e/k/t/u

Re: defvar'ing constants

[David Kastrup]

Jay Belanger <belanger@truman.edu> writes:

> "Richard M. Stallman" <rms@gnu.org> writes:
>
>>     For consistency:
>>
>>       (defvar CONSTANT)               ; should work
>>       (defvar CONSTANT ITS-VALUE)     ; should work
>>       (defvar CONSTANT OTHER-VALUE)   ; should fail
>>
>> I think it is more consistent to make them all errors.
>> defvar should not be used on these symbols.
>
> If a constant is defined in one file but used in a second, is there
> then a way of quieting the compiler when the second file is
> compiled?

(defconst CONSTANT)

would appear to be a nice form for doing that.  It is not valid right
now.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: defvar'ing constants

[Jay Belanger]

David Kastrup <dak@gnu.org> writes:
> Jay Belanger <belanger@truman.edu> writes:
...
>> If a constant is defined in one file but used in a second, is there
>> then a way of quieting the compiler when the second file is
>> compiled?
>
> (defconst CONSTANT)
>
> would appear to be a nice form for doing that.  It is not valid right
> now.

That would be nice.
A while back, there was a discussion along the lines of doing
something similar for functions,
(defun foo)
to keep the compiler happy.  I recall the idea (not mine) meeting
approval.  Perhaps it's still planned for a future release?

Jay

Re: defvar'ing constants

[Stefan Monnier]

>     For consistency:
>       (defvar CONSTANT)               ; should work
>       (defvar CONSTANT ITS-VALUE)     ; should work
>       (defvar CONSTANT OTHER-VALUE)   ; should fail

> I think it is more consistent to make them all errors.
> defvar should not be used on these symbols.

One case I know was consciously make to work is (defvar :foo :foo) so that
packages using :foo could be kept backward compatible with Emacs-19
where :foo is a normal variable because keywords don't exist.
Whether we should still cater to such thing is another question.


        Stefan

Re: defvar'ing constants

[Juanma Barranquero]

On 6/28/05, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
> >     For consistency:
> >       (defvar CONSTANT)               ; should work
> >       (defvar CONSTANT ITS-VALUE)     ; should work
> >       (defvar CONSTANT OTHER-VALUE)   ; should fail

> One case I know was consciously make to work is (defvar :foo :foo) so that
> packages using :foo could be kept backward compatible with Emacs-19
> where :foo is a normal variable because keywords don't exist.

Aha, that's why set-default and friends go around a few hoops to allow
setting a keyword to itself. Thanks! Anyway, that was allowed in my
original patch (it's the second case shown above) but I removed it per
Richard's request. I can re-add it if deemed appropriate.

> Whether we should still cater to such thing is another question.

No idea whether it will be usual for people with Emacs 22.X to load
19.X packages :)

-- 
                    /L/e/k/t/u

Re: defvar'ing constants

[Richard M. Stallman]

    One case I know was consciously make to work is (defvar :foo :foo) so that
    packages using :foo could be kept backward compatible with Emacs-19
    where :foo is a normal variable because keywords don't exist.
    Whether we should still cater to such thing is another question.

I had forgotten about that, because Emacs 19 was so long ago.

I think it is ok to forget about this, but _if_ the change bothers
people, we could change defvar to once again allow that case and that
case only.

Re: defvar'ing constants

[Stephen J. Turnbull]

Sorry this is old; getting back into emacs-devel after a long hiatus.

>>>>> "Jay" == Jay Belanger <belanger@truman.edu> writes:

    Jay> That would be nice.  A while back, there was a discussion
    Jay> along the lines of doing something similar for functions,
    Jay> (defun foo) to keep the compiler happy.  I recall the idea
    Jay> (not mine) meeting approval.  Perhaps it's still planned for
    Jay> a future release?

XEmacs has a whole suite of macros for checking whether things are
boundp or fboundp, and for locally declaring them to be f?boundp to
the compiler without using def* macros.  We have found them very
useful in suppressing spurious compiler warnings.  If there is
interest in using this code, they are not yet assigned to the FSF, but
at the present time they are 100% written by Ben Wing <ben@xemacs.org>
as far as I know.  You might ask Ben to assign the code and avoid
redundant work on this.

The only advantage I see over the (defvar foo) approach is that you
avoid spurious tags, but this can be convenient.

These macros do not require any changes to the byte-compiler (in
XEmacs, anyway), and can even be placed in a separate library and
require'd only in the files where they are used.  (I don't recommend
this, just demonstrating that they don't interfere with the normal byte
compiler.)

Cheers,

-- 
School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
               Ask not how you can "do" free software business;
              ask what your business can "do for" free software.

Re: defvar'ing constants

[Richard M. Stallman]

      If there is
    interest in using this code, they are not yet assigned to the FSF, but
    at the present time they are 100% written by Ben Wing <ben@xemacs.org>
    as far as I know.  You might ask Ben to assign the code and avoid
    redundant work on this.

Experience says it isn't worth the effort to ask.  He would need
papers from Sun as well as signing them himself.