defvaralias

defvaralias

[Luc Teirlinck]

The old docstrings of define-obsolete-{function,variable}-alias
contained statements that if no docstring was provided, that is,
`(define-obsolete-{function,variable}-alias 'old 'new)', then OLD
would get the docstring of NEW, _unless_ it already had one.  This has
been replaced with references to the `defalias' and `defvaralias '
docs, which have no such "unless" statements.  The "unless" appears to
be definitely false in the `function' case.  But it is true in the
variable case.  That is because it is false for defalias, but true for
defvaralias.

There are two solutions for the variable case.  Document the fact in
the docstring and Elisp documentation of defvaralias, or make
defvaralias behave exactly like defalias and get rid of the "unless"
behavior.  I prefer the latter.  The patch below would implement
it.  I can install if desired.

To be more concrete:

After:

(defvar var1 "DOC1")
(defvar var2 "DOC2")
(defvaralias 'var1 'var2)

C-h v var1 RET

now shows "DOC1", whereas after the patch below it shows "DOC2", which
is behavior consistent with defalias.

===File ~/eval.c-diff=======================================
*** eval.c	03 May 2005 20:44:24 -0500	1.237
--- eval.c	05 May 2005 19:42:50 -0500	
***************
*** 747,752 ****
--- 747,754 ----
    LOADHIST_ATTACH (symbol);
    if (!NILP (docstring))
      Fput (symbol, Qvariable_documentation, docstring);
+   else
+     Fput (symbol, Qvariable_documentation, Qnil);
  
    return aliased;
  }
============================================================

Re: defvaralias

[Luc Teirlinck]

>From my previous message:

   After:

   (defvar var1 "DOC1")
   (defvar var2 "DOC2")
   (defvaralias 'var1 'var2)

should have been:

   After:

   (defvar var1 nil "DOC1")
   (defvar var2 nil "DOC2")
   (defvaralias 'var1 'var2)

Sincerely,

Luc.

defvaralias

[Nick Roberts]

Luc Teirlinck writes:
 > The old docstrings of define-obsolete-{function,variable}-alias
 > contained statements that if no docstring was provided, that is,
 > `(define-obsolete-{function,variable}-alias 'old 'new)', then OLD
 > would get the docstring of NEW, _unless_ it already had one.  This has
 > been replaced with references to the `defalias' and `defvaralias '
 > docs, which have no such "unless" statements.  The "unless" appears to
 > be definitely false in the `function' case.  But it is true in the
 > variable case.  That is because it is false for defalias, but true for
 > defvaralias.

That was my mistake. I looked at the behaviour of defvaralias and assumed
defalias behaved the same way.

 > There are two solutions for the variable case.  Document the fact in
 > the docstring and Elisp documentation of defvaralias, or make
 > defvaralias behave exactly like defalias and get rid of the "unless"
 > behavior.  I prefer the latter.  The patch below would implement
 > it.  I can install if desired.
 > 
 > To be more concrete:
 > 
 > After:
 > 
 > (defvar var1 "DOC1")
 > (defvar var2 "DOC2")
 > (defvaralias 'var1 'var2)

I think if an alias is made only then only one of the variables needs to be
declared.

 > C-h v var1 RET
 > 
 > now shows "DOC1", whereas after the patch below it shows "DOC2", which
 > is behavior consistent with defalias.

As Stefan has pointed out defvaralias has a symmetry in its arguments (unlike
define-obsolete-variable-alias neither) but clearly it would make sense to be
consistent with defalias.

Nick

Re: defvaralias

[Luc Teirlinck]

Nick Roberts wrote:
    
    > (defvar var1 "DOC1")
    > (defvar var2 "DOC2")
    > (defvaralias 'var1 'var2)

   I think if an alias is made only then only one of the variables needs to be
   declared.

So the idea of the present behavior would be to do a
(defvaralias 'var1 'var2) with a defvar for var1 instead of for var2?
I do not believe that would be appropriate.

   As Stefan has pointed out defvaralias has a symmetry in its
   arguments (unlike define-obsolete-variable-alias neither)

I do not understand.  The variable alias structure is a directed
graph, not an undirected graph.  The arguments to defvaralias are
asymmetric in their meaning.  The first argument is the alias, the
second the base variable.

(defvaralias 'var1 'var2)

is different (in non-trivial ways) from 

(defvaralias 'var2 'var1)

in as far as `indirect-variable', cyclic variable indirection errors
and such are concerned.

Sincerely,

Luc.

Re: defvaralias

[Nick Roberts]

Luc Teirlinck writes:
 > Nick Roberts wrote:
 >     
 >     > (defvar var1 "DOC1")
 >     > (defvar var2 "DOC2")
 >     > (defvaralias 'var1 'var2)
 > 
 >    I think if an alias is made only then only one of the variables needs to be
 >    declared.
 > 
 > So the idea of the present behavior would be to do a
 > (defvaralias 'var1 'var2) with a defvar for var1 instead of for var2?
 > I do not believe that would be appropriate.

I mean:

(defvar var2 "DOC2")
(defvaralias 'var1 'var2)

is doesn't give compiler warnings. Presumably defvaralias is a declaration
for var1.

 >    As Stefan has pointed out defvaralias has a symmetry in its
 >    arguments (unlike define-obsolete-variable-alias neither)
 > 
 > I do not understand.  The variable alias structure is a directed
 > graph, not an undirected graph.  The arguments to defvaralias are
 > asymmetric in their meaning.  The first argument is the alias, the
 > second the base variable.
 > 
 > (defvaralias 'var1 'var2)
 > 
 > is different (in non-trivial ways) from 
 > 
 > (defvaralias 'var2 'var1)
 > 

Yes, you're right and I'm misquoting Stefan. There must be some symmetry,
however as:

(defvar var2 "DOC2")
(defvaralias 'var1 'var2)
(defvar var1a "DOC1")
(defvaralias 'var1a 'var2a)

doesn't give compiler warnings either.


Nick


 > in as far as `indirect-variable', cyclic variable indirection errors
 > and such are concerned.
 > 
 > Sincerely,
 > 
 > Luc.

Re: defvaralias

[Luc Teirlinck]

Nick Roberts wrote:

   I mean:

   (defvar var2 "DOC2")
   (defvaralias 'var1 'var2)

Of course, but I did a prior (defvar var1 "DOC1") to give var1 a
docstring.  Apart from that the (defvar var1 "DOC1") is really bad.  A
defvaralias form, like a defalias form, constitutes a definition and
one should not define var1 twice with different definitions.  But how
else do I give var1 a prior docstring other than manually manipulating
the variable-documentation property of var1 before doing the
defvaralias, which I should not be doing either?

Sincerely,

Luc.

Re: defvaralias

[Stefan Monnier]

>    (defvar var2 "DOC2")
>    (defvaralias 'var1 'var2)

> Of course, but I did a prior (defvar var1 "DOC1") to give var1 a
> docstring.  Apart from that the (defvar var1 "DOC1") is really bad.  A
> defvaralias form, like a defalias form, constitutes a definition and
> one should not define var1 twice with different definitions.  But how
> else do I give var1 a prior docstring other than manually manipulating
> the variable-documentation property of var1 before doing the
> defvaralias, which I should not be doing either?

What's wrong with (defvaralias 'var1 'var2 "var1 docstring") ?


        Stefan

Re: defvaralias

[Luc Teirlinck]

Stefan Monnier wrote:

   What's wrong with (defvaralias 'var1 'var2 "var1 docstring") ?

Nothing.  What we are struggling with is an unintentional misfeature
whereby if var1 already has a docstring then after
`(defvaralias 'var1 'var2)' it keeps its docstring instead of getting
var2's docstring as intended and currently documented.  This really
never should matter, as it can only occur if var1 has two competing
definitions, a defvar or defcustom and a defvaralias, which should not
happen.  My example with the deliberately bad code was meant to
illustrate the misfeature.

I proposed a small trivial patch to eliminate the misfeature, but
Richard said that this constituted an incompatible change and that we
should document the feature and tell people not to use it since the
feature will be eliminated in Emacs 23.  (I have a hard time
understanding why this is an incompatible change, since the function
defvaralias in _new_ in Emacs 22, and the behavior only can occur if
there already is a bug anyway.)

Sincerely,

Luc.

Re: defvaralias

[Luc Teirlinck]

>From my previous message:
  
  and the behavior only can occur if there already is a bug anyway.

Well, bug is probably not the correct word.  The behavior can only
occur if there is already very unclean code.

Sincerely,

Luc.

Re: defvaralias

[Richard Stallman]

    (defvar var2 "DOC2")
    (defvaralias 'var1 'var2)

    is doesn't give compiler warnings. Presumably defvaralias is a declaration
    for var1.

In theory, it should warn, but I would rather put that in TODO
and not change it now.

    Yes, you're right and I'm misquoting Stefan. There must be some symmetry,
    however as:

    (defvar var2 "DOC2")
    (defvaralias 'var1 'var2)

That should not warn.  It defines var2 once and var1 once.

    (defvar var1a "DOC1")
    (defvaralias 'var1a 'var2a)

That should warn.  It defines var1a twice.

But this can wait till after the release.

Re: defvaralias

[Luc Teirlinck]

Nick Roberts wrote:

   As Stefan has pointed out defvaralias has a symmetry in its arguments

Looking at the old message, I believe that what Stefan said is that in
defvaralias (unlike in `define-obsolete-variable-alias'), there are no
"old" and "new" variables or "obsolete" and "updated" variables.
(With which I agree.)  But that is not the same as saying that there
is symmetry.  The asymmetry in the relation is that one is the alias,
the other the base variable.

Sincerely,

Luc.

Re: defvaralias

[Richard Stallman]

    There are two solutions for the variable case.  Document the fact in
    the docstring and Elisp documentation of defvaralias, or make
    defvaralias behave exactly like defalias and get rid of the "unless"
    behavior.  I prefer the latter.

I think that is cleaner, but it is also an incompatible change.
I'd rather warn people we will change this after version 22.

Re: defvaralias

[Luc Teirlinck]

Richard Stallman wrote:

   I think that is cleaner, but it is also an incompatible change.
   I'd rather warn people we will change this after version 22.

But the function is new in 22.1, so if we change this in 23, we have
aberrant behavior for just one single release.  All current
documentation, including the NEWS, describes the behavior as being
what the behavior _would_ be after my patch.  So the current actual
behavior appears to be unintentional.  The change only affects
docstrings, so can not introduce severe bugs.  The change only makes a
difference in cases which should not really occur to begin with (at
least not in the Emacs source code): a variable defined twice, once
with defvar and once with defvaralias.

Not making the small code change would require the documentation
(docstring, Elisp manual and NEWS) to become more complex.  We would
have to document the exceptional case and then warn that it will go
away in Emacs 23.

Sincerely,

Luc.

Re: defvaralias

[Richard Stallman]

       I think that is cleaner, but it is also an incompatible change.
       I'd rather warn people we will change this after version 22.

    But the function is new in 22.1,

The ChangeLog files say it was present in 21.1.
If it were new in 22.1 then indeed we could change it painlessly now.

Re: defvaralias

[Luc Teirlinck]

Richard Stallman wrote:

       But the function is new in 22.1,

   The ChangeLog files say it was present in 21.1.

That is indeed true.   The confusion arose because I forgot that `C-h v
did not work for variables defined in the C code in 21.3.

Sincerely,

Luc.

Re: defvaralias

[Luc Teirlinck]

>From my pevious message:

   That is indeed true.   The confusion arose because I forgot that `C-h v
   did not work for variables defined in the C code in 21.3.

I of course meant that I forgot that `C-h f" did not work for
functions defined in the C code (such as defvaralias).

Sincerely,

Luc.

Re: defvaralias

[Juanma Barranquero]

> That is indeed true.   The confusion arose because I forgot that `C-h v
> did not work for variables defined in the C code in 21.3.

Uh?

  *** Welcome to IELM ***  Type (describe-mode) for help.
  ELISP> (defvar *x* 1)
  *x*
  ELISP> (defvaralias '*y* '*x*)
  *** Eval error ***  Symbol's function definition is void: defvaralias
  ELISP> emacs-version
  "21.3.1"
  ELISP> 

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

Re: defvaralias

[Luc Teirlinck]

Juanma Barranquero wrote;

   > That is indeed true.   The confusion arose because I forgot that `C-h v
   > did not work for variables defined in the C code in 21.3.

   Uh?

     *** Welcome to IELM ***  Type (describe-mode) for help.
     ELISP> (defvar *x* 1)
     *x*
     ELISP> (defvaralias '*y* '*x*)
     *** Eval error ***  Symbol's function definition is void: defvaralias
     ELISP> emacs-version
     "21.3.1"
     ELISP> 

You are right.  I guess I just forgot _how_ I checked it yesterday.
After seeing Richard's message, I just _assumed_ that I must have done
something wrong.

Richard, shall I go ahead and install my patch then?

Sincerely,

Luc.

Re: defvaralias

[Juanma Barranquero]

> The ChangeLog files say it was present in 21.1.
> If it were new in 22.1 then indeed we could change it painlessly now.

Luc's right. The first reference to defvaralias is:

  2001-10-04  Gerd Moellmann  <gerd@gnu.org>

        This adds `defvaralias' and `indirect-variable'.  Changes not
        directly related to this feature are there to gain the same
        performance again as before variable aliases.

and the previous entry on ChangeLog.9 is:

  2001-10-04  Gerd Moellmann  <gerd@gnu.org>

        * Branch for 21.1.

so it seems like Gerd branched for 21.1 and immediately afterwards
commited a bunch of things on the main trunk, `defvaralias' among
them.

It's a little weird, though. `defvaralias' is mentioned on
lisp\ChangeLog on 21.[1-4]:

  2001-05-20  Gerd Moellmann  <gerd@gnu.org>

        * font-lock.el (lisp-font-lock-keywords-1): Add `defvaralias'.

and the corresponding font-lock code indeed has:

  "(\\(def\\("
  ;; Function declarations.
  "\\(advice\\|varalias\\|alias\\|generic\\|macro\\*?\\|method\\|"
  [etc]

even when the function is not available.

And, from 21.2+, lisp\w32-fns.el has this:

  ;; Set system coding system initially from locale-coding-system.
  ;; In future, when defvaralias is available, this will become an alias.
  (set-w32-system-coding-system locale-coding-system)

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

Re: defvaralias

[Richard Stallman]

    so it seems like Gerd branched for 21.1 and immediately afterwards
    commited a bunch of things on the main trunk, `defvaralias' among
    them.

Thanks for noticing this.  This being so, let's make the change in doc
string handling change now.

Re: defvaralias

[Luc Teirlinck]

Richard Stallman wrote:

   This being so, let's make the change in doc string handling change now.

Done.

Sincerely,

Luc.

Re: defvaralias

[Richard Stallman]

    There are two solutions for the variable case.  Document the fact in
    the docstring and Elisp documentation of defvaralias, or make
    defvaralias behave exactly like defalias and get rid of the "unless"
    behavior.  I prefer the latter.

I think the latter is cleaner, but it is also an incompatible change.
I'd rather warn people we will change this after version 22.

defvaralias

[Luc Teirlinck]

Output of C-h f defvaralias:

defvaralias is a built-in function.
(defvaralias SYMBOL ALIASED &optional DOCSTRING)

Make SYMBOL a variable alias for symbol ALIASED.  

Setting the value of SYMBOL will subsequently set the value of ALIASED, 
and getting the value of SYMBOL will return the value ALIASED has.
ALIASED nil means remove the alias; SYMBOL is unbound after that.
Third arg DOCSTRING, if non-nil, is documentation for SYMBOL.

My remarks:

This suggests that (defvaralias 'var nil) will make `var' cease to be
an alias if it was one and unbind var, if var was bound.  Instead, var
becomes, pretty logically, an alias for `nil'.  I looked at the code
in eval.c and the code makes not the slightest attempt to implement
any special behavior when ALIASED is `nil'.  I propose to just remove
the next to last line in the doc string and could commit this change
if desired.  I just want to make sure that the described behavior is
not _really_ intended (and hence the bug would be in the code rather
than in the doc string).

Sincerely,

Luc.

Re: defvaralias

[Miles Bader]

Luc Teirlinck <teirllm@dms.auburn.edu> writes:
> This suggests that (defvaralias 'var nil) will make `var' cease to be
> an alias if it was one and unbind var, if var was bound.  Instead, var
> becomes, pretty logically, an alias for `nil'.  I propose to just remove
> the next to last line in the doc string and could commit this change
> if desired.

Conceptually, `making a variable an alias for nil' seems like a
confusing way of doing (defconst VAR nil); in practice, it additionally
makes it impossible to set the variable (but I'm not sure this is
particularly useful, compared to say, more general enforcement of
defconst).  Removing a variable alias _does_ seem like a useful
function, so wouldn't it make more sense to make the code follow the
doc-string?

-Miles
-- 
Yo mama's so fat when she gets on an elevator it HAS to go down.

Re: defvaralias

[Luc Teirlinck]

Miles Bader wrote:

   Removing a variable alias _does_ seem like a useful function, so
   wouldn't it make more sense to make the code follow the doc-string?

I have no strong opinion on the subject.  I just want the function and
its doc string to be in sync, which can be accomplished either way.
But one of the two needs to be done.

Sincerely,

Luc.

Re: defvaralias

[Richard Stallman]

Please do make the docstring fit the behavior of the function.