Perhaps the way to do ad-hoc "variable" assignment at the top level
for exploratory, interactive purposes is to call SET:
* (set 'foo 'bar)
rather than
* (setq foo 'bar)
when we are introducing a "variable" "on the fly"?
The former would be better than the latter because, even if we ignore
the implementation(s) gratuitously issuing a special proclamation when
evaluating a top-level SETQ form for a symbol which is not a variable
[1], we may still encounter the annoyance of warnings in the latter
case---not to mention that the effect of such a form is in fact
undefined. On the other hand, using SET in this way has the advantage
of being brief over the equivalent call to SETF of SYMBOL-VALUE, which
is obviously too cumbersome for the above purpose.
A disadvantage of SET is that it is deprecated, but this seems a much
lesser evil.
[1] It is probably redundant to point out that it follows from
3.1.2.1.1 Symbols as Forms and 3.1.2.1.1.2 Dynamic Variables
that, if (SETQ FOO 'BAR) has the first occurrence of FOO, then
in fact FOO is not a variable there.
---Vassil.
--
The truly good code is the obviously correct code.
Vassil Nikolov <···············@pobox.com> writes:
> Perhaps the way to do ad-hoc "variable" assignment at the top level
> for exploratory, interactive purposes is to call SET:
>
> * (set 'foo 'bar)
>
> rather than
>
> * (setq foo 'bar)
>
> when we are introducing a "variable" "on the fly"?
IMO, it doesn't happen often enough to warrant this response.
Btw, the reason its discouraged is also to avoid confusion about lexical
vs special, and especially not to get caught up in a debate about whether
global lexicals and global specials share a common value cell, or whether
they have independent toplevel cells. If you make non-special assignment
easier to do, you risk that the people doing it will not understand that
they are setting the symbol-value, and when that happens, they may not
realize they are invoking the special variable mechanism. (Arguably,
some set of names to make this more clear, like symbol-dynamic-value
rather than symbol-value might have made this even more clear, if a pain
to type.)
> The former would be better than the latter because, even if we ignore
> the implementation(s) gratuitously issuing a special proclamation when
> evaluating a top-level SETQ form for a symbol which is not a variable
> [1], we may still encounter the annoyance of warnings in the latter
> case---not to mention that the effect of such a form is in fact
> undefined.
The standard requires no warnings. If a vendor is bugging you, bug
the vendor back. The market is intended to sort warnings out. It's
true some vendors nag people. Personally, I wouldn't put up with it.
There are other vendors that don't. And anyway, surely the vendors
that do have a variable you can set once for all time in an init file
to turn them off.
> On the other hand, using SET in this way has the advantage
> of being brief over the equivalent call to SETF of SYMBOL-VALUE, which
> is obviously too cumbersome for the above purpose.
You could always shadow SET and do this for yourself if you cared.
If it were offered by the language, myriad users would confuse themselves,
as they frequently used to do, by using SET in other contexts and not being
able to understand why it doesn't work.
> A disadvantage of SET is that it is deprecated, but this seems a much
> lesser evil.
SET was deprecated so that people would stop using the name, allowing
it to ultimately be freed up for ... drum roll, please, ... sets.
Such as you get with SET-DIFFERENCE. Using it up for so capricious an
end as a return to making a bad programming style more accessible
would seem sad.
All just my personal opinion, though.
In article <··············@localhost.localdomain>,
Vassil Nikolov <···············@pobox.com> wrote:
> On 07 Jun 2007 00:56:31 -0400, Kent M Pitman <······@nhplace.com> said:
> | ...
> | If it were offered by the language, myriad users would confuse themselves,
> | as they frequently used to do, by using SET in other contexts and not being
> | able to understand why it doesn't work.
>
> I have missed all that fun...
>
> | SET was deprecated so that people would stop using the name, allowing
> | it to ultimately be freed up for ... drum roll, please, ... sets.
> | Such as you get with SET-DIFFERENCE. Using it up for so capricious an
> | end as a return to making a bad programming style more accessible
> | would seem sad.
>
> | All just my personal opinion, though.
>
> Thank you for it. I can't make a stronger case, and in the light of
> your response the thing to do is probably to define a new function
> or macro for this kind of purpose, one that will be easy to enter
> and that will make it difficult or impossible or at least annoying
> to use with file compilation (and that possibly will have other
> properties to be determined after experimentation).
The new function is already there. SET was deprecated because its
functionality is now provided by SETF of SYMBOL-VALUE, i.e.
(set SYM VAL) == (setf (symbol-value SYM) VAL)
The fact that it's more verbose was not considered a problem, as this
was expected to be a relatively uncommon thing to do.
--
Barry Margolin, ······@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 ***
On Sat, 09 Jun 2007 00:23:49 -0400, Barry Margolin <······@alum.mit.edu> said:
| In article <··············@localhost.localdomain>,
| Vassil Nikolov <···············@pobox.com> wrote:
|| ...
|| the thing to do is probably to define a new function
|| or macro for this kind of purpose, one that will be easy to enter
|| and that will make it difficult or impossible or at least annoying
|| to use with file compilation (and that possibly will have other
|| properties to be determined after experimentation).
| The new function is already there. SET was deprecated because its
| functionality is now provided by SETF of SYMBOL-VALUE, i.e.
| (set SYM VAL) == (setf (symbol-value SYM) VAL)
| The fact that it's more verbose was not considered a problem, as this
| was expected to be a relatively uncommon thing to do.
It seems to me that setting variables ad hoc during interactive,
exploratory sessions (e.g. to hold arguments or results) happens
often enough to be worth a short name, and I am thinking along the
lines of
(defmacro setv (&whole form variable value)
"Set the dynamic value of a variable.
Intended only for interactive use."
`(progn
(eval-when (:compile-toplevel)
(warn "Non-interactive use: ~S." ',form)) ;cerror?
(setf (symbol-value ,variable) ,value)))
for such a new macro. (To be refined.)
---Vassil.
--
The truly good code is the obviously correct code.
Vassil Nikolov <···············@pobox.com> writes:
> On Sat, 09 Jun 2007 00:23:49 -0400, Barry Margolin <······@alum.mit.edu> said:
>
> | In article <··············@localhost.localdomain>,
> | Vassil Nikolov <···············@pobox.com> wrote:
>
> || ...
> || the thing to do is probably to define a new function
> || or macro for this kind of purpose, one that will be easy to enter
> || and that will make it difficult or impossible or at least annoying
> || to use with file compilation (and that possibly will have other
> || properties to be determined after experimentation).
>
> | The new function is already there. SET was deprecated because its
> | functionality is now provided by SETF of SYMBOL-VALUE, i.e.
>
> | (set SYM VAL) == (setf (symbol-value SYM) VAL)
>
> | The fact that it's more verbose was not considered a problem, as this
> | was expected to be a relatively uncommon thing to do.
>
> It seems to me that setting variables ad hoc during interactive,
> exploratory sessions (e.g. to hold arguments or results) happens
> often enough to be worth a short name, and I am thinking along the
> lines of
Well, it seems that for that purpose, the existing SETQ (is this one
also to be deprecated?) or SETF is likely to be sufficient. It seems to
me that it is really unlikely that one would want to actually EVALUATE
the argument to produce the location that one wants to set during an
interactive session.
> (defmacro setv (&whole form variable value)
> "Set the dynamic value of a variable.
> Intended only for interactive use."
> `(progn
> (eval-when (:compile-toplevel)
> (warn "Non-interactive use: ~S." ',form)) ;cerror?
> (setf (symbol-value ,variable) ,value)))
>
> for such a new macro. (To be refined.)
But for interactive use on a particular variable that you want to
affect, this would require you to write
(setv 'foo 3)
instead of the unquoted version
(setf foo 3)
Do you often find yourself in a situation where there is previously
you have something like
(setq var 'bar)
And then need to do something like
(set var 8)
to change the value of BAR? I suppose that you would then need to use
something like
(eval var) ; or
(symbol-value var)
in order to see the value.
--
Thomas A. Russ, USC/Information Sciences Institute
In article <···············@sevak.isi.edu>,
···@sevak.isi.edu (Thomas A. Russ) wrote:
> Vassil Nikolov <···············@pobox.com> writes:
>
> > On Sat, 09 Jun 2007 00:23:49 -0400, Barry Margolin <······@alum.mit.edu>
> > said:
> >
> > | In article <··············@localhost.localdomain>,
> > | Vassil Nikolov <···············@pobox.com> wrote:
> >
> > || ...
> > || the thing to do is probably to define a new function
> > || or macro for this kind of purpose, one that will be easy to enter
> > || and that will make it difficult or impossible or at least annoying
> > || to use with file compilation (and that possibly will have other
> > || properties to be determined after experimentation).
> >
> > | The new function is already there. SET was deprecated because its
> > | functionality is now provided by SETF of SYMBOL-VALUE, i.e.
> >
> > | (set SYM VAL) == (setf (symbol-value SYM) VAL)
> >
> > | The fact that it's more verbose was not considered a problem, as this
> > | was expected to be a relatively uncommon thing to do.
> >
> > It seems to me that setting variables ad hoc during interactive,
> > exploratory sessions (e.g. to hold arguments or results) happens
> > often enough to be worth a short name, and I am thinking along the
> > lines of
>
> Well, it seems that for that purpose, the existing SETQ (is this one
> also to be deprecated?) or SETF is likely to be sufficient. It seems to
> me that it is really unlikely that one would want to actually EVALUATE
> the argument to produce the location that one wants to set during an
> interactive session.
He's trying to get around the undefined behavior of using toplevel
SETQ/SETF on a variable that hasn't been declared with
DEFVAR/DEFPARAMETER, or maybe just silence the warnings that many
implementations print. This restriction doesn't exist when you use SET.
--
Barry Margolin, ······@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 ***
On Mon, 11 Jun 2007 20:43:59 -0400, Barry Margolin <······@alum.mit.edu> said:
| In article <···············@sevak.isi.edu>,
| ···@sevak.isi.edu (Thomas A. Russ) wrote:
|| Vassil Nikolov <···············@pobox.com> writes:
|| ...
|| > It seems to me that setting variables ad hoc during interactive,
|| > exploratory sessions (e.g. to hold arguments or results) happens
|| > often enough to be worth a short name, and I am thinking along the
|| > lines of [(SETV foo bar) as a broad analog of (SET foo bar)]
||
|| Well, it seems that for that purpose, the existing SETQ (is this one
|| also to be deprecated?) or SETF is likely to be sufficient. It seems to
|| me that it is really unlikely that one would want to actually EVALUATE
|| the argument to produce the location that one wants to set during an
|| interactive session.
| He's trying to get around the undefined behavior of using toplevel
| SETQ/SETF on a variable that hasn't been declared with
| DEFVAR/DEFPARAMETER, or maybe just silence the warnings that many
| implementations print.
Yes---both. Then occasionally I find myself doing things roughly
along the lines of, for example,
(setf (symbol-value 'vars) '#(foo bar)) ;<=> (setv 'vars '#(foo bar))
(setf (symbol-value (aref vars i)) (baz i ...)) ;<=> (setv (aref vars i) (baz i ...))
(quux foo)
(quuux bar)
(again, only in an interactive, "exploratory" session), which is why
I am thinking of having the first argument to SETV to be
evaluated---depending on what further experience shows, of course
(thus "to be refined").
| This restriction doesn't exist when you use SET.
But, of course, as Kent Pitman rightly pointed out, SET is subject
to other restriction, hence the quest for yet another operator.
---Vassil.
--
The truly good code is the obviously correct code.