Real constants

Real constants

[Juanma Barranquero]

This is *not* a proposed change for 22.1; more of a question about a
feature, or lack of it.

Having the possibility of marking a symbol as constant (not in the
`defconst' sense, but really constant) seems so potentially useful and
so trivial to implement (vide the attached patch), that I can only
suppose there's some reason, or perceived problem, not to have done it
till now.

Could someone please explain the rationale for not having true
constants in elisp?

Thanks,

                    /L/e/k/t/u



Index: src/eval.c
===================================================================
RCS file: /cvsroot/emacs/emacs/src/eval.c,v
retrieving revision 1.250
diff -u -2 -r1.250 eval.c
--- src/eval.c	13 Jul 2005 05:31:35 -0000	1.250
+++ src/eval.c	13 Jul 2005 13:49:29 -0000
@@ -956,4 +956,37 @@
     }
 }
+
+DEFUN ("set-constant-p", Fset_constant_p, Sset_constant_p, 2, 2, 0,
+       doc: /* Set constant state of SYMBOL to FLAG.
+When FLAG is non-nil, SYMBOL becomes constant; otherwise, it is variable.
+Keywords, ie symbols satisfying `keywordp', are always constant.  */)
+     (symbol, flag)
+     Lisp_Object symbol, flag;
+{
+  CHECK_SYMBOL (symbol);
+
+  if (EQ (Fkeywordp (symbol), Qt))
+    error ("Cannot change constant state of keyword `%s'",
+           SDATA (SYMBOL_NAME (symbol)));
+
+  XSYMBOL (symbol)->constant = EQ (flag, Qt);
+
+  return symbol;
+}
+
+DEFUN ("constantp", Fconstantp, Sconstantp, 1, 1, 0,
+       doc: /* Return t if SYMBOL is a constant.
+If so, its value cannot be changed.
+The `constant'ness of a symbol can be changed with `set-constant-p'.  */)
+     (symbol)
+     Lisp_Object symbol;
+{
+  CHECK_SYMBOL (symbol);
+
+  if (XSYMBOL (symbol)->constant)
+    return Qt;
+  return Qnil;
+}
+
 \f
  DEFUN ("let*", FletX, SletX, 1, UNEVALLED, 0,
@@ -3561,4 +3594,6 @@
   defsubr (&Sdefconst);
   defsubr (&Suser_variable_p);
+  defsubr (&Sset_constant_p);
+  defsubr (&Sconstantp);
   defsubr (&Slet);
   defsubr (&SletX);

Re: Real constants

[Stefan Monnier]

> This is *not* a proposed change for 22.1; more of a question about a
> feature, or lack of it.

> Having the possibility of marking a symbol as constant (not in the
> `defconst' sense, but really constant) seems so potentially useful and
> so trivial to implement (vide the attached patch), that I can only
> suppose there's some reason, or perceived problem, not to have done it
> till now.

> Could someone please explain the rationale for not having true
> constants in elisp?

I believe it's mostly because it wasn't nearly as trivial/cheap until Gerd
installed his defvaralias patch, which also introduced the `constant' field
in symbols.

Among the local patches I use, I've expanded this `constant' field to
2 bits, so it can be either hard-read-only or soft-read-only (or writable,
of course).  The soft-read-only state is used by defconst so that variables
defined by defconst cannot be setq but can be changed via defconst
(important when you reload a new version of a package where a defconst was
changed).

Making defconst variables into constants introduces a few occasional
problems with some packages, of course, but nothing too hard to fix.


        Stefan

Re: Real constants

[Juanma Barranquero]

On 7/13/05, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> I believe it's mostly because it wasn't nearly as trivial/cheap until Gerd
> installed his defvaralias patch, which also introduced the `constant' field
> in symbols.

Yeah, I meant "trivial now", of course. But that's been in Emacs for
what? Five years?

> Among the local patches I use, I've expanded this `constant' field to
> 2 bits, so it can be either hard-read-only or soft-read-only (or writable,
> of course).  The soft-read-only state is used by defconst so that variables
> defined by defconst cannot be setq but can be changed via defconst
> (important when you reload a new version of a package where a defconst was
> changed).

Do you allow un-const'ing things? If so, special care should be taken
with `enable-multibyte-characters', nil, t and perhaps a few others...

> Making defconst variables into constants introduces a few occasional
> problems with some packages, of course, but nothing too hard to fix.

And in fact I'd bet most of these problems are, if not bugs, at least
bad style... :)

Could you please post your code here? I think it would be a great
feature (after 22.1).

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

Re: Real constants

[Stefan Monnier]

> Yeah, I meant "trivial now", of course. But that's been in Emacs for
> what? Five years?

There's no released Emacs with defvaralias, so it's still recent.

>> Among the local patches I use, I've expanded this `constant' field to
>> 2 bits, so it can be either hard-read-only or soft-read-only (or writable,
>> of course).  The soft-read-only state is used by defconst so that variables
>> defined by defconst cannot be setq but can be changed via defconst
>> (important when you reload a new version of a package where a defconst was
>> changed).

> Do you allow un-const'ing things?

No.  But I could make `defvar' un-const a defconst if that's necessary.

> If so, special care should be taken with `enable-multibyte-characters',
> nil, t and perhaps a few others...

These are hard-read-only so they can't be redefined with defconst
or un-const'd.

>> Making defconst variables into constants introduces a few occasional
>> problems with some packages, of course, but nothing too hard to fix.

> And in fact I'd bet most of these problems are, if not bugs, at least
> bad style... :)

Yes, most.  But for some the fix is not too elegant either.
Typical problems:

- The const-value can't be conveniently constructed at top-level:

   (defvar foo nil)
   (defvar bar nil)
   (let ((blabla))
     (setq foo (toto blabla))
     (setq bar (toto blabla)))

  Removing the defvars and replacing the setq with defconst is correct, but
  the byte-compiler is a bit dumb and don't realize that foo and bar are
  both unconditionally defined, so it may warn of unknown variables.

- name clashes.  E.g.

    (defconst e 2.718281828459045)
  ...
    (let ((b (match-beginning 0))
          (e (match-end 0)))
  ...

- there are also other cases where a const-var is not quite constant: some
  part of the code (or some advice, or hook) wants to temporarily let-bind
  it to some other value.

> Could you please post your code here? I think it would be a great
> feature (after 22.1).

I doubt it'll ever make its way into Emacs: it introduces compatibility
problems without bringing any clear benefit.


        Stefan

Re: Real constants

[Richard M. Stallman]

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 motivation for the suggestion appears to be an idea of
completeness.  Emacs has a bit that makes a symbol constant, so why
not add a construct to set that bit.  But adding features for mere
completeness would mean doing a lot of extra work for little or no
benefit.

Please don't propose new Emacs features for mere completeness' sake.

Re: Real constants

[Juanma Barranquero]

On 7/14/05, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> There's no released Emacs with defvaralias, so it's still recent.

That is true, but seems a joke... :)

> No.  But I could make `defvar' un-const a defconst if that's necessary.

Aha.

> These are hard-read-only so they can't be redefined with defconst
> or un-const'd.

OK.

>   Removing the defvars and replacing the setq with defconst is correct, but
>   the byte-compiler is a bit dumb and don't realize that foo and bar are
>   both unconditionally defined, so it may warn of unknown variables.

In this case you should `defvar' them (to make them known to the
byte-compiler), and then `defconst' them to make unmodifiable. If
there were ever to exist true constants in Emacs (which I see Richard
is vetoing), the ability to switch the constness state would be
necessary.

> - name clashes.  E.g.

The only answer to this would be to make sure constants have
significant, hard-to-repeat-by-accident names. Instead of `e', that
should be `number-e' or `*number-e*' or `transcendent-constant-e' or
whatever.

> I doubt it'll ever make its way into Emacs:

That seems correct.

Thanks,

                    /L/e/k/t/u

Re: Real constants

[Juanma Barranquero]

On 7/14/05, Richard M. Stallman <rms@gnu.org> wrote:

> I don't want to introduce defining of "real constants" in Emacs.

That's your prerogative, of course.

> The motivation for the suggestion appears to be an idea of
> completeness.

No. It's not completeness, it's usefulness, even if you don't agree
(you were commenting about *my* motivations, after all :)

  - Most languages have true constants, even dynamic languages like
Perl (though in Perl they're really inlined functions). This case
(Perl) is particularly funny because it started without constants and
they were added afterwards when they were found lacking (and useful).

 - True constants can prevent some kinds of problems.

  - The Emacs code already uses true constants, like
`enable-multibyte-characters', and keywords. Was that for
completeness?

 - At least one developer (Stefan) has said he has true constants
added to his local Emacs. I'd assume he finds them useful.

> Please don't propose new Emacs features for mere completeness' sake.

Please don't assume you know people's motivations or needs.

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

Re: Real constants

[Richard M. Stallman]

     - True constants can prevent some kinds of problems.

      - The Emacs code already uses true constants, like
    `enable-multibyte-characters', and keywords. Was that for
    completeness?

enable-multibyte-characters is not a constant.  It is a special
builtin weird hack.  Keywords are a specific feature.

These were useful in specific ways.  Are user-defined constants
useful in specific ways?

    > Please don't propose new Emacs features for mere completeness' sake.

    Please don't assume you know people's motivations or needs.

No motive was mentioned for adding a primitive to set the flag except
that the flag exists.  That's "completeness' sake".

Re: Real constants

[Juanma Barranquero]

On 7/15/05, Richard M. Stallman <rms@gnu.org> wrote:

> These were useful in specific ways.  Are user-defined constants
> useful in specific ways?

Aren't user-defined constants useful in other languages? Isn't it
useful per se to be able to set a symbol and guarantee that the user,
or another module, is not going to change it by accident? Certainly
Common Lisp is not above having constants
(http://www.lisp.org/HyperSpec/Body/mac_defconstant.html), and at
least some implementations treat them as true constants:

  ;;; An error occurred in function COMPILE-FORM:
  ;;; Error: The symbol *Z* has been declared constant, and may not be
assigned to

What do you ask for? An example? What if the constants define absolute
sizes of external resources (like, for example,
`bindat--fixed-length-alist') and every single attempt to change them
could be considered an error (and possibly crash Emacs)?

> No motive was mentioned for adding a primitive to set the flag except
> that the flag exists.  That's "completeness' sake".

No, that's "I assumed the value of real constants in programming
languages was way beyond needing a rationale"... Perhaps I'm assuming
too much.

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

Re: Real constants

[Stefan Monnier]

>  - True constants can prevent some kinds of problems.

That seems to be the only real motivation (the others are more like "why not
have it"?).  I must say it's pretty vague.  AFAICT in 99.9% of the cases
constants have the following uses:

- catch programming errors.  This is similar to type annotations, modules,
  etc... and does not enable anything.  It's only used for software
  engineering purposes.
- allow the compiler to generate more efficient code.

I don't think Richard considers either of them as something
particularly important.

>  - At least one developer (Stefan) has said he has true constants
>    added to his local Emacs. I'd assume he finds them useful.

I like to experiment with primitives in order to get a better idea of what
the code out there looks like.  E.g. my local Emacs's strings are
non-mutable.  I.e. I like to try and add some constraint which seems to be
generally not broken, and see if/where it gets broken.  This is a general
technique to learn to understand some unknown piece of code.

Of course I also strongly believe in non-mutable objects, so I like the idea
of constants and non-mutable strings, but I know it's a waste of time to try
and include those things in elisp.


        Stefan

Re: Real constants

[Thien-Thi Nguyen]

Juanma Barranquero <lekktu@gmail.com> writes:

> Aren't user-defined constants useful in other languages?

the only user-defined constant is ignorance.
(with programmers, this is a variable concept. :-)

thi

Re: Real constants

[Richard M. Stallman]

    Aren't user-defined constants useful in other languages? Isn't it
    useful per se to be able to set a symbol and guarantee that the user,
    or another module, is not going to change it by accident?

I don't see a need for this.

     Certainly
    Common Lisp is not above having constants

I don't want to add features to Emacs Lisp just because other
languages, even other Lisp dialects, have them.  That would be a
recipe for adding lots more features, each of which would be work to
maintain, work to document, etc.

    What do you ask for? An example? What if the constants define absolute
    sizes of external resources (like, for example,
    `bindat--fixed-length-alist') and every single attempt to change them
    could be considered an error (and possibly crash Emacs)?

That is a case where the feature would provide no practical benefit,
because the magnitude of the problem in practice is zero.  It would be
more elegant in some conceptual sense if these symbols could not be
altered.  But that would not translate into any benefit for Emacs
users, or for us Emacs maintainers.

    No, that's "I assumed the value of real constants in programming
    languages was way beyond needing a rationale"... Perhaps I'm assuming
    too much.

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

Re: Real constants

[Richard M. Stallman]

    > Aren't user-defined constants useful in other languages?

    the only user-defined constant is ignorance.
    (with programmers, this is a variable concept. :-)

This should go in the Emacs humor file.

Re: Real constants

[Juanma Barranquero]

On 7/16/05, Richard M. Stallman <rms@gnu.org> wrote:

> This should go in the Emacs humor file.

I'll put in the file I'm going to add (some day or other) in etc.

Wrt constants, I'll drop the issue.

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

Re: Real constants

[Juanma Barranquero]

On 7/15/05, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> That seems to be the only real motivation (the others are more like "why not
> have it"?).

Well, I won't say that. It's more: "why not use them for the same uses
that they have in other languages". And moreover, having defconst's
which don't "const" is cognitive dissonance.

> E.g. my local Emacs's strings are
> non-mutable.  I.e. I like to try and add some constraint which seems to be
> generally not broken, and see if/where it gets broken.  This is a general
> technique to learn to understand some unknown piece of code.

Interesting.

> Of course I also strongly believe in non-mutable objects, so I like the idea
> of constants and non-mutable strings, but I know it's a waste of time to try
> and include those things in elisp.

Yeah, I know now, too.

Thanks,
                    /L/e/k/t/u