From: joubert.nel on 4 Mar 2007 12:59 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 4 Mar 2007 13:26 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 4 Mar 2007 14:51 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 5 Mar 2007 01:10 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 5 Mar 2007 01:44 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
|
Next
|
Last
Pages: 1 2 3 Prev: A style question Next: Ltk + Slime + Mac OSX 10.4 + (Clisp or SBCL or OpenMCL or CMUCL) |