From: joubert.nel on
Hi,

The expression
(defparameter *name* initial-value)
unconditionally evaluates initial-value and then assigns its result to
*name*

Contrasting, the expression
(defvar *name* initial-value)
will only evaluate initial-value and assign its result to *name* if
the latter is not already bound.

So, are the following two possibilities equivalent?
1: (defparameter *name* "Joubert Nel")

2: (defvar *name*)
(setf *name* "Joubert Nel")

and, as a 3rd possibility,assuming *name* is not already bound, then
either (defparameter ...) or (defvar ...) would be OK.
The latter saves on some wrist-action :-)

If this is all so, I'm wondering why you would (defvar ....) a
variable if it is already in use except perhaps to change its
documentation? Perhaps I just haven't run into situations where this
is useful...

Joubert

From: Barry Margolin on
In article <1173031152.532101.272630(a)30g2000cwc.googlegroups.com>,
joubert.nel(a)gmail.com wrote:

> Hi,
>
> The expression
> (defparameter *name* initial-value)
> unconditionally evaluates initial-value and then assigns its result to
> *name*
>
> Contrasting, the expression
> (defvar *name* initial-value)
> will only evaluate initial-value and assign its result to *name* if
> the latter is not already bound.
>
> So, are the following two possibilities equivalent?
> 1: (defparameter *name* "Joubert Nel")
>
> 2: (defvar *name*)
> (setf *name* "Joubert Nel")

Yes.

>
> and, as a 3rd possibility,assuming *name* is not already bound, then
> either (defparameter ...) or (defvar ...) would be OK.
> The latter saves on some wrist-action :-)
>
> If this is all so, I'm wondering why you would (defvar ....) a
> variable if it is already in use except perhaps to change its
> documentation? Perhaps I just haven't run into situations where this
> is useful...

This happens all the time when you reload the entire file, presumably to
fix a bug in one of the functions. You don't want the reload to set
variables back to their default values when the user has customized them.

--
Barry Margolin, barmar(a)alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***
From: Ken Tilton on


Barry Margolin wrote:
> In article <1173031152.532101.272630(a)30g2000cwc.googlegroups.com>,
> joubert.nel(a)gmail.com wrote:
>
>
>>Hi,
>>
>>The expression
>> (defparameter *name* initial-value)
>>unconditionally evaluates initial-value and then assigns its result to
>>*name*
>>
>>Contrasting, the expression
>> (defvar *name* initial-value)
>>will only evaluate initial-value and assign its result to *name* if
>>the latter is not already bound.
>>
>>So, are the following two possibilities equivalent?
>>1: (defparameter *name* "Joubert Nel")
>>
>>2: (defvar *name*)
>> (setf *name* "Joubert Nel")
>
>
> Yes.
>
>
>>and, as a 3rd possibility,assuming *name* is not already bound, then
>>either (defparameter ...) or (defvar ...) would be OK.
>>The latter saves on some wrist-action :-)
>>
>>If this is all so, I'm wondering why you would (defvar ....) a
>>variable if it is already in use except perhaps to change its
>>documentation? Perhaps I just haven't run into situations where this
>>is useful...
>
>
> This happens all the time when you reload the entire file, presumably to
> fix a bug in one of the functions. You don't want the reload to set
> variables back to their default values when the user has customized them.
>

Right. A softer reason is the self-documenting quality that says (when
the variable goes uninitialized) that this bad boy is bound dynamically
at run time.

kt

--
Well, I've wrestled with reality for 35 years, Doctor, and
I'm happy to state I finally won out over it.
-- Elwood P. Dowd

In this world, you must be oh so smart or oh so pleasant.
-- Elwood's Mom
From: Vassil Nikolov on

On Mon, 05 Mar 2007 09:45:10 +0530, Madhu <enometh(a)meer.net> said:
| ...
| Except you can't set the documentation string if you want it to be
| uninitialized.

But that is proper. A docstring belongs with a definition, and a
DEFVAR form that leaves a variable uninitialized isn't much of a
definition. As a matter of style, I believe that

(declaim (special *foo*))

is to be preferred to

(defvar *foo*) ;this variable intentionally left unbound

(regrettably, I can't trace the origin of this advice to give proper
credit).

---Vassil.


--
Is your code free of side defects?
From: Ken Tilton on


Vassil Nikolov wrote:
> On Mon, 05 Mar 2007 09:45:10 +0530, Madhu <enometh(a)meer.net> said:
> | ...
> | Except you can't set the documentation string if you want it to be
> | uninitialized.
>
> But that is proper. A docstring belongs with a definition, and a
> DEFVAR form that leaves a variable uninitialized isn't much of a
> definition. As a matter of style, I believe that
>
> (declaim (special *foo*))

PWUAHAHAHAHHAHAHAHHHAHAHHHAHAHAAA!!!!!!

I thought I was anal.

>
> is to be preferred to
>
> (defvar *foo*) ;this variable intentionally left unbound

Listen, when His Kennyness deigns to speak to you unworthies, just bow
and scrape and leave the NG without turning your back on Himself. Do
/not/ forget the offering plate.

docstrings? docstrings?!!!!!!! Read my lips: if you cannot name one
frickin variable without creating confusion, can you imagine how much
confusion you will create by writing a whole sentence?!!!

>
> (regrettably, I can't trace the origin of this advice to give proper
> credit).

I found it!:

(defvar *cll-bozo-depth* 0 "OK, gosh, this is gonna be tricky, this is
like, I am responding to a bozo, I mean, not how deep in the water they
are depth, or how profound they are, but see, there was this other bozo
I was responding to, ok, call that depth zero, and then a second bozo
stepped in, hope that covers it, gotta run, pizza's here.")

Hmm, I like it, mebbe I was wrong. Nah, I was just inordinately precise
and lucid compared to all the other doc I've ever read. Scary, that.

<There is so little hope for you people.>

kenny

--
Well, I've wrestled with reality for 35 years, Doctor, and
I'm happy to state I finally won out over it.
-- Elwood P. Dowd

In this world, you must be oh so smart or oh so pleasant.
-- Elwood's Mom