defvar vs setqif..

defvar vs setqif..

[D. Goel]

One often finds multiple defvar's for a single variable in libraries
and specially in .emacs ..  This is because people use (defvar 'foo)
at the top-level, when they mean to: (if (unboundp 'foo) (defvar
foo))..    There's no difference but the former affects tags,
find-function etc. etc. when it shouldn't...

An example: my .emacs needs to, say, (add-hook 'foo-mode-hook... ),
but the hook may not be defined, so i (defvar foo-mode-hook) before
this statement. The problem is that this would lead to etags and
find-function marking those places.

If there was a special-form that did exactly what defvar does, hopefully
people would stop using defvar when they didn't mean to...

I would not like if this new special-form started with a 'def'.. because
often it is convenient to ask etags to tag anything starting with
'def..' ... specially useful if you define your own defunn's and
defun-my etc. 

So i was wondering is a special-form like 'setqif' could be provided
whose only difference from 'defvar' is in a name...


D				   <http://www.glue.umd.edu/~deego/>
-- 

Re: defvar vs setqif..

[Colin Walters]

On Sun, 2002-05-19 at 16:44, D. Goel wrote:

> An example: my .emacs needs to, say, (add-hook 'foo-mode-hook... ),
> but the hook may not be defined, so i (defvar foo-mode-hook) before
> this statement. 

Why do you defvar it?  The best solution is to (require 'foo-mode)
before adding the hook.  But `add-hook' won't lose if the hook isn't
bound yet.

Re: defvar vs setqif..

[Miles Bader]

Colin Walters <walters@verbum.org> writes:
> > An example: my .emacs needs to, say, (add-hook 'foo-mode-hook... ),
> > but the hook may not be defined, so i (defvar foo-mode-hook) before
> > this statement. 
> 
> Why do you defvar it?  The best solution is to (require 'foo-mode)
> before adding the hook.  But `add-hook' won't lose if the hook isn't
> bound yet.

...and the above defvar won't bind it anyway...

-Miles
-- 
I'd rather be consing.

Re: defvar vs setqif..

[D. Goel]

> On Sun, 2002-05-19 at 16:44, D. Goel wrote:
> 
> > An example: my .emacs needs to, say, (add-hook 'foo-mode-hook... ),
> > but the hook may not be defined, so i (defvar foo-mode-hook) before
> > this statement. 
> 
> Why do you defvar it?  The best solution is to (require 'foo-mode)
> before adding the hook. 

true i guess, but not always carried out... that's why the issue
arises in the first place..   One reason it is not always carried out
is:

say a user wants to frob a thousand variables in their .emacs or their
own private library...  they don't want to (require) all the involved
libraries, thus slowing down the loading of emacs.. so the user simply
make sures the variables are defined via defvar, and then runs
(add-to-list) or whatever on these variables..

authors who may do similar stuff in their libraries may have the same
reason---not wanting to slow down the loading by (requiring 'stuff).
So they may defvar variables of that libaray...



> But `add-hook' won't lose if the hook isn't bound yet.


yeah very true.. bad example, sorry :).. how about (add-to-list) ?  :)




D				   <http://www.glue.umd.edu/~deego/>
-- 

Re: defvar vs setqif..

[Thien-Thi Nguyen]

"D. Goel" <deego@glue.umd.edu> writes:

   say a user wants to frob a thousand variables in their .emacs or their
   own private library...  they don't want to (require) all the involved
   libraries, thus slowing down the loading of emacs.. so the user simply
   make sures the variables are defined via defvar, and then runs
   (add-to-list) or whatever on these variables..

there's a better way to do this: use `eval-after-load'.  for example:

  ;; not recommended: using "forward declarations"
  (defvar foo)	; from foo-package
  (munge foo)

  ;; recommended: delaying evaluation until after some package is loaded
  (eval-after-load "foo-package"
    '(munge foo))

note that the form needs to be quoted unless its evaluation is to return the
actual form to be evaluated (after/when foo-package is loaded).

thi

Re: defvar vs setqif..

[Stefan Monnier]

>   ;; recommended: delaying evaluation until after some package is loaded
>   (eval-after-load "foo-package"
>     '(munge foo))

Note that you can also use (eval-after-load 'foo-package '(munge foo))
which will also work if someone does (load "/bla/bla/foo-package")
or (load "foo-package.elc").
On the other hand, it only works if the corresponding package correctly
does (provide 'foo-package) at the end.


	Stefan

Re: defvar vs setqif..

[D. Goel]

Thi and Stefan..
cool info.. thanks


D				   <http://www.glue.umd.edu/~deego/>
-- 

Re: defvar vs setqif..

[Kai Großjohann]

"D. Goel" <deego@glue.umd.edu> writes:

> say a user wants to frob a thousand variables in their .emacs or their
> own private library...  they don't want to (require) all the involved
> libraries, thus slowing down the loading of emacs.. so the user simply
> make sures the variables are defined via defvar, and then runs
> (add-to-list) or whatever on these variables..

IMHO, this is a bad idea.  The intention of add-to-list is to add
something to whatever the value was before, right?  And before the
add-to-list, the most meaningful value would be the default value
(instead of nil).

Now, if a variable has a non-nil default value, then your suggestion
means it will have a very short value: just the single item you put
in it.  So

    (defvar foo)
    (add-to-list 'foo 'item)

could as well have been written 

    (setq foo '(item))

Now, most lists should have nil default values, to facilitate
Customize.  But your argument strikes me as a bad argument: to add
something to the default value, users will have to require the
corresponding *.el file anyway.

Or am I misunderstanding something here and way too tired?

kai
-- 
Silence is foo!

Re: defvar vs setqif..

[Richard Stallman]

    > An example: my .emacs needs to, say, (add-hook 'foo-mode-hook... ),
    > but the hook may not be defined, so i (defvar foo-mode-hook) before
    > this statement. 

    Why do you defvar it?  The best solution is to (require 'foo-mode)
    before adding the hook.

That is often a costly solution, because it forces loading of
foo-mode.el.  If you package always needs foo-mode, the price must be
paid anyway.  But when it does not always need foo-mode, you should
not require it at load time.

Re: defvar vs setqif..

[Miles Bader]

"D. Goel" <deego@glue.umd.edu> writes:
> If there was a special-form that did exactly what defvar does, hopefully
> people would stop using defvar when they didn't mean to...

The way they're using defvar is correct.

It would be much better to fix the definition-finding functions to
prefer defvars that initialize the variable over those that don't, since
the `real' definition almost always initializes the value (and should).

> So i was wondering is a special-form like 'setqif' could be provided
> whose only difference from 'defvar' is in a name...

That name would be wrong, because the usage of defvar you're
complaining about doesn't set the variable at all.

In any case, we should just make defvar work correctly.

-Miles
-- 
`...the Soviet Union was sliding in to an economic collapse so comprehensive
 that in the end its factories produced not goods but bads: finished products
 less valuable than the raw materials they were made from.'  [The Economist]

Re: defvar vs setqif..

[D. Goel]

> > If there was a special-form that did exactly what defvar does, hopefully
> > people would stop using defvar when they didn't mean to...
> 
> The way they're using defvar is correct.

yeah, true.  i didn't mean to suggest otherwise.  i just mean that
defvar 

> 
> It would be much better to fix the definition-finding functions to
> prefer defvars that initialize the variable over those that don't, since
> the `real' definition almost always initializes the value (and should).


how can a definition-finding function tell which of the several
defvar's it may encounter.  AFAICT, there is no way for a
definition-finding function like tag-creation-function to tell which
is the 'defining' defvar and which is not...

> 
> > So i was wondering is a special-form like 'setqif' could be
> > provided whose only difference from 'defvar' is in a name...
> 
> That name would be wrong, because the usage of defvar you're
> complaining about doesn't set the variable at all.

but that's why i had an 'if' at the end.. to suggest that setq only if
not already defined.. else don't setq..

> 
> In any case, we should just make defvar work correctly.

mean? 



in any case, all this is a very 'cosmetic' issue.. no big deal if 
folks didn't like the idea :)

Have a good day,

D				   <http://www.glue.umd.edu/~deego/>
-- 

Re: defvar vs setqif..

[Stefan Monnier]

> how can a definition-finding function tell which of the several
> defvar's it may encounter.  AFAICT, there is no way for a
> definition-finding function like tag-creation-function to tell which
> is the 'defining' defvar and which is not...

There should be only one (defvar <var> <val>) form per variable.
All others should only be (defvar <var>).
Admittedly, this cannot always be done conveniently, but I don't
think the problematic cases happen often, far from it.
Do you have evidence otherwise ?

> but that's why i had an 'if' at the end.. to suggest that setq only if
> not already defined.. else don't setq..

When have you needed that ?
(I mean actual concrete examples)


	Stefan

Re: defvar vs setqif..

[D. Goel]

> 
> There should be only one (defvar <var> <val>) form per variable.
> All others should only be (defvar <var>).


this resolves it for me.. i've been overlooking this...  i guess i now
see what all of you have been trying to tell me.  sorry to have wasted
all of your times...And indeed, as Miles was saying, the tag-finding
functions would/should know this rule...

re: actual concrete examples, indeed i have no examples when my TAGS
has ended up getting double-tags for a variable where the 2 tags come
from 2 libraries.. i guess this must be due to the reason you
mentioned above....  neither has my TAGS ever created a tag for a
defvar in my my .emacs even though my set-tags probes my .emacs and my
.emacs does have defvar's..  this must all be because the 'offending'
defvar's must be following the syntax you mention above..  So i humbly
withdraw my suggestion..

(there is one minor duplication---my TAGS seems to probe the
loaddefs-my.el too and creates 2 tag-entries for each autoloaded
defun/defvar---one where it was defined, and one for
loaddefs-my.el.. but that is quite unrelated to the present issue.. i
should simply request tags.el to overlook loaddefs-my.el when creating
TAGS, i guess..)..



Have a good day,

D				   <http://www.glue.umd.edu/~deego/>
-- 

Re: defvar vs setqif..

[Miles Bader]

"D. Goel" <deego@glue.umd.edu> writes:
> > > So i was wondering is a special-form like 'setqif' could be
> >
> > That name would be wrong, because the usage of defvar you're
> > complaining about doesn't set the variable at all.
> 
> but that's why i had an 'if' at the end.. to suggest that setq only if
> not already defined.. else don't setq..

I guess this is already resolved, but just to make sure things are
clear, `defvar' without an initializer _never_ binds or sets the variable.
In fact it shouldn't affect the variable at all, only meta-information
about the variable.

-Miles
-- 
Quidquid latine dictum sit, altum viditur.

Re: defvar vs setqif..

[D. Goel]

> `defvar' without an initializer _never_ binds or sets the variable.

yeah i was confused.. i knew this was true for common-lisp..  But
don't know why i assumed that if 'foo is unbounded, then (defvar foo)
binds it to nil.  i just checked the doc and that's untrue..

> In fact it shouldn't affect the variable at all, only
> meta-information about the variable.

thanks. 


D				   <http://www.glue.umd.edu/~deego/>
--